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.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".
2002.05.07 ~17 "static" support in q3asm
Ogg Vorbis reference library makes a few uses of the static keyword for
some functions. Staticness is recognized by q3lcc, and it shows in its
assembly output; static functions do not have their symbols flagged for
exporting. The linker, q3asm, blithely ignores staticness, along the
lines of: else if (!strcmp(token, "export")) { } else ...
In effect, all functions are exported; static functions aren't static.
Although I already patched Ogg Vorbis to be static-less, WIBNI
q3asm properly understood the [not] exporting function symbols.
2002.05.07 ~04 Q3 libc
My reimplementation of various additional Standard C functions for Q3VM is
growing large enough to be its own project. I'm thinking of moving the
files into a directory of its own, in both the CVS and (home) web trees.
The game/ directory is starting to fill up with too many bg_* files.
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
