Raw source and immediate archive at
http://www.icculus.org/~phaethon/plan/Entries are currently sorted in: Newest First
Syntax (time and date in UTC, my local timezone is PST/PDT):
[YEAR].[MONTH].[DAY] <space> ~[APPROX. HOUR] <space> <space> [SUMMARY]
<empty line>
[CONTENT]
<empty line>
<empty line>
2002.06.01 ~16 'dows woes
Local gamehenger Chunky Kibbles ranted about Windows XP.
Reminded me of my wrastling with it's incestuous parent, W98.
So here's the gig. I play Tribes 2 under our favorite penguin's choice of
OS. For one reason and another, the T2 builtin VoIP are (a) incompatible
between T2.Linux and T2.Windows, (b) just plain sucks in general.
The T2 tribe/clan I'm in uses an out-of-game VoIP called "Roger Wilco", by
Resounding Technology(?), now a wholly-owned subsidiary of GameSpy Industry
(GSI), another company I have some serious beef against. To put a long
story short, RW is available only for Windows. Well, there's the "server"
end of RW (to relay packets) available for Linux, but that's about it. No
actual codec'ing under the penguin.
Cue WINE. It failed miserably.
Cue my hand-me-down laptop computer from my sister. This laptop suffered a
very dead screen when someone accidently stepped on its closed form while
unattended, cracking the LCD screen. No one fessed up. In the time since,
she has (a) gotten a desktop worthy of... Counter... counter-something FPS,
(b) stopped being a nomad requiring a portable. This machine I have dubbed
Polyphemos, after the cyclops who's (single) eye was poked out by Odysseus
in Oddyssey -- the screen does sort of look like someone took a pole
straight at it, albeit way off to the left side.
It's a Pentium II-based Celeron/400, with a meaty 64MB RAM, and 4GB HDD,
imbued with the curse known as Windows 98SE, and a Phoenix BIOS that is
hopelessly glued to the hip of FAT FS for Save-To-Disk. It has since been
sprinkled with the holy water known as Debian GNU/Linux, but it still
suffers from split personality, primarily because of the Save-To-Disk.
On the darker side of its personality, there was a mass of cruft collected
over two years of use by my sister. I wanted to reclaim much of the space
so that (a) lots of 'dows crap will be rid, (b) I can set up a Q3 server.
This, as far as I can recall, is the first time I voluntarily elected to
boot into Windows since 1997 (all other boots since being involutary,
forced, or otherwise accidental). I decided to start on diskspace
recovery. Calling upon skills lost and buried since 1997, I managed to get
to "Add/Remove Programs" and started picking on anything starting with
"Microsoft". Click remove. "Are you sure you want to remove" type dialog
box. Yes. "Windows now requires a reboot for the uninstallation to be
complete" type dialog box. No, I have more cruft to remove. Go on
selecting a few more, with the same cycle of Yes and No. Can't think of
anything else, so close the control panel thingy and reboot.
The programs didn't disappear.
They stayed there, in the dialog box and all the menus, mocking at my vain
attempts at removing them. The sadistic humor dawned on me. The only way
I was going to remove all this cruft was by individually relecting them for
removal... and rebooting after each and every selection.
After rebooting probably more times in two hours than everyone on lkml does
during an entire x.{odd-number}.y development cycle, combined, I came to
the issue of lookOut Express. For security reasons, I wanted this gone
gone gone. But, lo and behold, it failed to list itself in the Add/Remove
doohickey. I could probably attack the binary directly, but, knowing the
predecessor Windows 95, that would leave all sorts of cruft behind, perhaps
even more cruft than before deletion. So, at three in the morning local
time, I visited the only place where I knew others dabbled in the dark side
of the force, #linpeople.
The instructions I received weren't hope-inspiring, but it was something:
grab MSIE6 to install IE6 and OE6 so they appear in the Add/Remove, then
remove. I should note at this point that networking has not yet worked
under Windows. Under my sister's usage, it interfaced to a USB-to-Ethernet
dongle (borrowed from a friend, and returned since). Under Linux, the
machine uses a Linksys PCM100 PCMCIA card (which works great). Apparently
Windows doesn't know how to use this. I started the download of the 30MB
zip file at a *cough*whopping 22KB/s (of 150 cap) to my main desktop. In
the interim, I fiddled with other stuff. After a significant portion of
this zip file came through, I realized how Windows could be made to
recognize and use the Ethernet card. This was shortly after, out of
desperation, I reopened the box the Ethernet card came in. Sitting in
there was a floppy disk.
In some ways, I probably spent too much time in GNU land. I had LONG
forgotten that in Windows, device drivers are packed with the hardware,
rather than the operating system. Plop in floppy, and hope for the best.
It crashed once upon attempting to install the driver. I should probably
specify that the installer crashed, not Windows as a whole. That happened
a short while later.
Try again, says driver got installed... and needs reboot.
Reboot.
OK, so it continues with whatever the hell Windows does for driver
installation. Then came more sadistic jokes. BEFORE the shell even
started, IT REBOOTED AGAIN. No prompt! No shell! Poof, reboot! WTF?!
Navigate GRUB menu for the nth time...
Install Mozilla 1.0rc3. Reboot again...
Eventually the IE6 zip finishes. Now to get it get from desktop to this
laptop. Network Neighborhood? Claims I didn't enter a password for
networking.
Try a different tact -- pull over HTTP (using Mozilla and Apache).
That worked.
But there's nothing that understands ZIP. I have no idea why my sister
never bothered with that WinZip thingy.
Visit cygwin.com. More installations. Least I get bash now. And reboot
wasn't required. Nice change of pace for once.
Unpack ZIP, run. Dunno why I have to agree to a license agreement when I
want to wind up removing OE. IE6 and OE6 install.
The GRUB menu is starting to get annoyingly familiar and frequent.
Post-reboot rest-of-installation of IE6 and OE6.
Really, seeing GRUB again so quickly can gnaw on your bones.
Then I proceed to select IE6 *and* OE6 for removal.
*sigh* Maybe I should patch GRUB for animation or something.
Removing IE6 and OE6 only managed to restore the previous OE and IE, MSIE5
and MSOE5. These don't appear for removal. So I look for OE's base
directory, looking for uninst-something.exe. There isn't any. On a mad
(both senses of the word) impulse, I exported the registry via regedit and
sicced grep upon it for anything mentioning "outlook" and "uninst". This
actually turned up something useful, the command line to remove MSOE5.
The invocation was such: "SETUP50.EXE /APP:OE /UNINSTALL /PROMPT". Query
if I want to remove. Of course yes.
And of course, we meet our dear friend GRUB yet again.
OE was the last thing that needed to be purged. IE is of course an
inseparable and integrated (... humor me) component of the operating
system, so I leave it be. Defrag time.
I forgot what I did during the wait. Maybe I ranted on IRC, maybe I tried
stupid rocket-jumping tricks in Quake 3, maybe I read Slashdot comments
back-to-back, maybe I measured glacier movements, maybe I fell asleep.
Eventually the defragmenting finished. Then it was time to install Roger
Wilco. Never knew a sunrise could feel so strange.
Installing RW went fairly straightforward, as Windows programs go. At
least GRUB could remain sleeping.
Some minor wiring to set it up as satisfactorily as possible. Microphone
to laptop's soundcard, laptop's soundout to desktop's line in, old PS/2
mouse plugged into laptop and used as the "transmit" button (with my foot).
Then I find out I won't be able to actually test this setup since the next
tribe practice is in two weeks time, as next week is filled completely with
matches.
Sigh.
TODO: rant about RW with emphasis on porting
TODO: rant about GSI
2002.05.27 ~00 PiNGer.JPEG
http://palmboxer.sourceforge.net/What is now known as ZBoxZ was known as Palmboxer, prior to a sawfishian
(re)naming... incident. ZBoxZ is a GPL'd file manager application, with
several satellite applications (plugins, if you will). Among them is
PiNGer, an image viewer, to view files packaged in "boxes" (some sort of
PDB encapsulation of files), which supposed displays GIF (87 and 89) and
PNG images. So far only PNG works (as an aside, the GIF portion was based
on gif2png, but a source check against gif2png 2.4.2 shows the GIF code in
PiNGer to be inconsistent).
I spent the last couple of days banging on PiNGer for JPEG support. One
breakthrough discovery (for me, at least) is an alternative PalmOS library
mechanism called "GLib" (no relation to GTK+'s glib). The original library
mechanism, SysLib, requires all library functions to take a library refnum
as their first argument. Eyemodule (a Handspring Visor camera thingy,
http://www.eyemodule.com) already did a port of IJG's JPEG library
("libjpeg") to PalmOS using the SysLib method, requiring a mass of wrapper
code to expect the refnum argument. Unfortunately, Eyemodule's JPEG port
only covers the compression half (i.e. from Eyemodule image data to
JPEG-in-PDB).
GLib, on the other hand, doesn't require this refnum passing doohickey. I
suspect this is based on using one of the spare registers on the M68K. In
any case, porting existing *nix libraries is more straightforward, since the
necessary state munging is left to the compiler instead of the developer.
There are still other brick walls, like the 32K code segment limit. Which
libjpeg slams into at 130KB.
Cue a prc-tools hack, the multiple resources mechanism. The basic idea is
to divvy up the code into a bunch of <32K segments, then glue them together
with jump tables. The developer still has to mark how the code will be
split, but the glue stuff is done automagically by the tools. This method
comes with a cost: reaching across the boundaries is time-consuming.
What is not clear to me, though, is whether using both GLib and multiple
resources is canon. I've already marked libjpeg for the various sections,
and already set it up for GLib-style shared-library compilation, but
linking this to PiNGer and using a jpeg function causes catastrophe.
Then I tried regular static library (.a) linkage without multi-res. That
broke 32K easily. Then I split up PiNGer and relinked. Near as I can
tell, it falls over when it dereferences a function pointer to a function
in another segment.
Nonetheless, my meddling in PalmOS programming is enlightening me on
matters of Q3 modding. In particular, toolchains, library, C extensions,
limited environment, assembly.
2002.05.23 ~11 Shazbot
Wow. Hit the end of that search quickly.
Bad news:
http://zerowing.idsoftware.com/archives/gtkrad-macos/2001-November/000096.htmlWorse news:
http://www.timedoctor.org/gimps/byzakk/bugging.jpgHeartening news:
http://zerowing.idsoftware.com/archives/gtkrad-macos/2001-November/000104.htmlConclusion: time to start groveling through (stock) LCC source. :(
2002.05.23 ~10 Where be them damn LCC patches
Google searches stumbled across J. Carmack's .plan entry for 26 Aug 1999,
mentioning "[the] modified LCC and q3asm will be available both in source
form and precompiled,...". I found the q3asm source, but I can't find the
damn patches to LCC. The biggest difference I can spot (between "canon"
LCC and Q3's LCC) is the usage of a special "pop" instruction added to the
Q3VM to no-oply consume the previous value (as with a void function (which
actually returns a value on the stack anyway) or an integer return value
not assigned to a variable). I'd rather not grovel through the LCC source
tree to try patching it up by hand into q3lcc.
2002.05.17 ~11 Project FI zlib
For the hell of it, I threw in zlib to the compile pipeline. Only two
modifications were needed to compile cleanly: (1) getting rid of "short"
(16-bit integer), which QVM bytecodes doesn't like for endian reasons, and
(2) defining fdopen(), which zlib manages to use some place. Actually,
fdopen just returns NULL (signifying error (to wit, "not implemented yet",
but errno isn't set properly (there's no EDAMNPROGRAMMERWASTOOLAZY))).
This is only sufficient to get an error-less compile. Actual (de)compres
has not been done. I'm not sure how the semantics would change, especially
since "short" was simply jacked up to a full "int" (32-bit), and there are
all sorts of short-based offsets and (de)referencing throughout zlib.
OTOH, Ogg Vorbis used arrays of shorts, and promoting those didn't break it
horribly.
The fdopen() whacking disturbs me, though. There's only one use of fopen
in zlib, and that's just to (re)generate the compile-time file trees.h.
All other functions related to I/O points back to fdopen(). Trying to
implement fdopen() in QVM is quite non-trivial. It basically goes
something like this: EOF is determined by recording the file length and
checking current file position against that. File length is obtained at
open time as the return value of trap_FS_FOpenFile. This trap will only
accept a file name (to specify a particular file). File name is not
recorded elsewhere by the trap, i.e. there is no native means of obtaining
the file name give the file handle/descriptor. In effect, given just a
file descriptor, EOF-ness cannot be determined, as the length is not
available. The return value of trap_FS_Read() will return the final
character of the file upon EOF; in this regard, a repeat character is
indistringuishable from EOF state.
There are a few attacks at this problem I can think of. One is writing
wrappers around the traps (the trap_*() are already wrappers around a
generalized syscall trampoline), to keep track of the fd-filename
association. Another is to just traverse the array of stream objects,
searching for any member that has a record (bad pun) of the given file
descriptor in hand, then resurrecting or copying the object. Another is to
cannibalize parts of PalmZlib that may help with regards to I/O (fdopen in
particular) in a crippled environment. Or maybe a combination. Yes,
perhaps a combination...
2002.05.16 ~06 QVM-bytecode libraries
I was pondering the separation of the libc files into a separate directory.
This would mean altering the compilation scripts (bash scripts) to
deliberately reach into the libc directory, compile each file to assembly,
then explicitly link the resulting files. Then I wondered how I could cut
down such tediousness (i.e. editing a couple files to list every single
file affected).
One method that sprung to mind was using ar(1), creating .a files for each
distinct library packages, e.g. libvorbis.a, libc.a, libz.a, etc. These .a
files contain distinct .o files, each derived from an associated .c file
(for the most part). The .a file can also contain a symbol table, an
association of symbols to locations within the .a and .o files. So for
each library package, an associated .a file is created. Then if some
symbol "funcfoo" was needed, the linker (q3ld?) can look through some
existing .a file (e.g. "libmystuff.a"), find "funcfoo" is defined in
"foo_bie.o", extract "foo_bie.o", and link it into the resulting qvm,
taking into account adjusted offsets.
The end result is a simplification in adding new external sources. I would
no longer need to edit the compile scripts to list every .c file to look
at, every .asm file to link. Instead, I would need only to compile each
"library package" separately into .a files, then leave the tasks of
searching and resolving to the linker.
To do the adjusted offsets (of symbols) would mean needing some kind of
structured format for the .o files to keep track of "normal" offsets.
Using an already existing format, such as a.out or COFF or ELF, would allow
using standard ar(1) and ranlib(1) to create the .a files (and its symbol
table). Doing so would also save me the trouble of trying to come up with
an appropriate format then re-extending it repeatedly in the future :)
This could mean utilizing GNU BFD in some form.
At this point, I realized something chilling. The .a files are
self-contained; they don't "depend" upon outside files for its content.
In other words, it would be very much "drop-in". Binary drop-in.
Libraries could be distributed without source.
2002.05.14 ~01 Nightmare flashback
So I was just driving along and out of the blue came a flashback of a
nightmare I had several years ago, when I was in middle school (jr. high).
Well, more like a recall, but "flashback" sounds more dramatic =)
The details are fuzzy, but the major points were basically these: a world
(or city, rather, as my "world view" at the time was rather small) where
there is a central "operating antenna", resembling a tower radio antenna,
by which automobiles are able to run. All automobiles in existence had to
check through the antenna in order to run at all; those that didn't failed
to start. So far things are already deviating pretty wildly from reality.
The scary part is when the antenna failed. It just lost power suddenly;
looked like a major power outage (blackout) to me. In any case, the
result was that all cars stopped immediately (engines just choked to death)
and could not be (re)started. I was stranded. Mind you, most of my life
was spent in and around Los Angeles, California, driven around by my dad
to one extracirricular activity to another. This is a city where "mass
transit infrastructure" is a Bill-Clintonism ("it depends on your
definition of 'mass transit'..."). So being stranded in some remote
place with means of transportation seemed plausible at the time.
So, anyway, thus far, this "central automobile antenna" died and all cars
were rendered useless on the spot until at such time power was restored
(and I don't remember that happening...). And so I was stranded in some
remote pocket of the world (or rather, L.A.). Far away from home. This
is rather terrifying for a 12-year-old raised in a "traditional" nuclear
family.
Sounds crazy so far. And rather irrelevant. But as I pondered through this
nightmare, I found a parallel to the modern world. Not cars (yet), but
rather software. Think about it. The fascist licensing models used by a
disturbingly increasing number of software [of any kind] where authorization
to run, much less even to start (or even install), must be cleared through
a centralized inet server. Should the connection be severed or denied, for
any reason, the software dies, perhaps taking (live) data with it.
This would be different kind of stranding, but just as terrifying as in
my nightmare. In some ways, more terrifying. Denied the means to support
myself (or be supported at all) by an external force beyond my control.
Should the central server undergo a sudden failure in existence, no amount
of money thrown anywhere will help resurrect such bondage software. And
without source, no amount of time spent will help either. And at the rate
current US legislation is headed, no amount of technical genius would help
either (as it would be outlawed).
I frequently reflect back on my views of Free software over the years since
I was first introduced to GNU software and stumbled upon the *nix universe.
At first, I found libre software to be "cool", as the philosophy of GNU and
other free software oufits happened to overlap much of my thoughts and
philosphy that I had developed independently of the *nix community,
interestingly enough (e.g. the value of source, the value of sharing, the
crazed notion of claiming loss of money never headed your way in the first
place). Then I found it "convenient", as Linux easily stepped around the
2GB BIOS fiasco (PC hard drives) of the late 90s, and Debian GNU/Linux
magically fixed itself from a libc5->libc6 bung-up (I still have no idea
how it did that; I swear I f*cked up the upgrade!). Then it became
"practical", as libre software let me do what I want to do, rather than be
limited by the [original] author's notion of what ought to be done (cases
in point: Window Maker customization, sawmill/sawfish customization, three
simult XFree86 sessions, massive cheats hacking into snes9x (Super Nintendo
emulator) like rapid-fire and joystick macros).
In some ways now, I see libre software as "critical". When I was 12, the
notion of automobiles umbilically tied to the functioning of a single
operations antenna terrified me. Nowadays, the notion that software being
similarly tied to a centralized inet server is fairly terrifying. The
notion that the mere existence of my data, and/or my ability to use my own
personal data, being intimately linked to the market performance of some
company, is contrarian to the notion of personal liberty, never mind
conflict of interest. If I'm driving a Ford F-150, I really don't want my
ability to start and drive the truck to be intimately linked to whether
Ford Motor Co. will decide to continue the line or not, or whether they
might declare bankruptcy today/tomorrow/next week.
In today's world, I (among many) would consider silly the idea that a car
would suddenly fail to work any more simply because the associated car
company said so. I'm not certain if contemporary proprietary software has
reached this far, but, to me, this seems a very likely scenario given
current trends of "subscription" (more like "rental") software. Libre
software certainly is among the solution to ensuring that the free market
stays free, without any one company's dictate controlling the activities of
any other company beyond the force of "The Market"/"The Invisible Hand".
Life: No Life found.
Project:
1. Project FI, Quake 3 mod (
http://www.icculus.org/fi/)
a. provide an extensible environment for a Q3 mod. The intended notion is that of "mutators" in Unreal Tournament.
b. FI:WFC, a more faithful reproduction of Q2WF for Q3 than WFA.
2. QuakeScheme
* Extensible language for Project FI.
* Builds on TinySCHEME (
http://tinyscheme.sourceforge.net/)
* Deal with idiosyncrasies of Q3VM not handled by most other Scheme impls.
3. QS GUI/widget set
a. Need to research advanced OO and GUI of Scheme derivatives and Common Lisp.
b. Replication/extension of boxy widgets in Q3TA (Q3 PR 1.27+).
c. Pie menus -- just to annoy theoddone33.
4. PalmOS stuff
a. PiNGer (gfx viewer)
* generalize interface to a "any-gfx" viewer (libpnm?)
b. ZBoxZ (file manager)
* beef up its appness: menus, dialogs, pen actions
