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>
2003.01.07 ~08 X10 Firecracker
Got one of those X10 Firecracker starter kits. The halogen lamp I
intend to control is rated 500W, so I had to purchase a separate
500W-capable X10 module. The transceiver that comes with the kit is
capable of 500W, but the lamp's socket is rather far from the 'puter.
The 300W dimmable module that came with the kit is currently unused. We
have no pluggable lamps under 300W.
The Firecracker dongle is tiny. I expected it to be at least half the
size of an average X10 module (which in itself is about the size of a
typical AC/DC power adapter). The Firecracker is small enough to be
mistaken for a mismanufactured serial gender-bender.
The Firecracker connects on the (9-pin) serial port and is a write-only
gadget. Lack of read ability is no matter, as I can get direct feedback
of any X10 action by turning my head.
Curently, to drive the Firecracker, I'm using Bottle Rocket. I have
GNOME launchers to control the lamp, for gawk-and-click controls.
2003.01.04 ~10 mark-and-partial-sweep garbage collection
This turned out to be an interesting hack to the mark-and-sweep gc. For
some reason, TinyScheme partitions its heap into N segments of M cons
cells. This appears inexplicable, as TinyScheme is hard-coded to use
only 3 of the segments and refuses to use any more segments (short of an
explicit procedure call to "new-segment").
I decided to use this inherent partitioning of the heap for a partial
sweep mechanism. Partly inspired by incremental-style garbage
collection (superset of "multi-threaded garbage collection"), the idea
was to sweep one segment per Q3 frame, so that the time to sweep up all
the garbage is spread out over a long time, interpersing regular Scheme
processing. This depends on the sweeper recovering garbage faster than
Scheme allocating space, which is most of the time (recovering up to M
cells per frame, vs allocating perhaps a dozen cells per frame). Each
module's vmMain() would need to call the partial sweeper once per frame
or somehow ensure the sweeper gets called frequently per second.
A problem is that in between partial sweeps, Scheme can still request
additional cells. By default, TinyScheme does not initiate garbage
collection until the heap is entirely exhausted. With this behavior,
Scheme may wind up requesting cells when the sweeper has barely started,
triggering another mark+sweep cycle. The free-at-exhausted behavior is
also annoying as it tends to lead to lost symbols and bindings (no
chance to establish a path from a root cell). As a workaround, I
changed TinyScheme to initiate garbage collection after the freelist
dips below a certain low mark, which is currently half a segment's size.
This way, fresh objects get a chance to join the marked tree, and the
allocator gets "padding" to keep Scheme satisifed as the sweeper starts.
I also had the sweeper watch for "extremely tight memory situations".
This would happen should Scheme allocate a very large chunk of memory
right after a mark pass (just as partial sweeping start). Since
sweeping when freelist hits zero tends to cause lost objects, I wanted
a non-zero panic point. Should the freelist drop below the panic point,
the sweeper goes into aggressive full-heap sweeping. Lacking a
reference for this panic point, I chose a random number, 42.
Empirically, on my K7/1200, with N=32 and M=32768 (total 1MiB), mark
phase takes about 5ms, and a partial sweep of one segment takes 18ms,
with a full-heap sweep taking a little under 600ms.
Wishlist items: somehow automagically setting partial sweep to stop
after a certain time threshold. One hack is to continually sample
elapsed time, but the call to get the time (a Q3VM trap) takes up
processing time. A better method would be to calculate the cells-per-ms
rate, then using an appropriate number-of-cells to finish a partial
sweep within time, but that method is more complicated.
2003.01.03 ~20 Showstopper in Scheme UI
Just ran across two showstopping bugs in implementing the entire ui
module in Scheme. The current garbage-collector algorithm is
mark-and-sweep. Even with a heap of 1MB, every gc cycle takes a
noticeable time to complete. This produces a heartbeat-like lag
pattern, where the entire UI just freezes up as the heap is marked and
swept. A clean solution is to use a garbage collector better suited to
realtime interactive use.
The other showstopper, partly related, is that due to the way TinyScheme
manages memory (to wit, symbols are not garbage-collected), the Scheme
subsystem eventually exhausts the heap after running the ui module for a
moderate time. Once the heap exhausts, anything can happen. Usually Q3
abends.
I'm thinking about falling back to my prior UI idea, which describes the
menus in S-expressions and uses Scheme as a Turing-complete language for
the more complex UI behaviors. This way, the most frequent actions
(drawing, repositioning, etc.) can be done in C or something, and leave
the less frequent actions (fancy animation, commands-wrapping) to Scheme
(less frequent garbage collecting).
2003.01.03 ~17 Undocumented feature of Q3VM's trap_FS_FOpenFile()
The trap never opens a filename beginning with "q3key". This is
filename, not pathname, so even "gfx/not/gfx/ha/ha/foold/you/q3keylist"
fails to open.
For my Scheme UI system, I'm rewriting the UI from scratch. I even have
a vmMain() replacement done in Scheme -- that low-level. Since I'm not
sure what's happening under the hood, and without a half-decent menu, I
can't get the console to open. I think it has to do with all those
repeat calls to trap_Key_SetCatcher, but I'm not that desperate to track
it down.
In any case, since the key event handler is also in Scheme, I wanted to
use symbolic names for the keysyms, instead of trying to figure out
numerical keycode. In particular, I wanted to use K_F12 to quit Q3
(since console is unreachable). So I wrote up a script to list out the
Q3 keysyms, assigning the appropriate keycodes to each symbol.
This list of definition went into a scheme file called "q3keys.cfg".
Scheme failed to find it (load "qs/q3keys.cfg"). I renamed it
"q3keys.scm", and it still couldn't find it. I tried debugging the
stdio, unistd, and devfs functions trying to find out what was wrong.
I traced flags, file modes, file permission. Everything looked fine.
Recalling that the Q3 CD key is stored in a file named "q3key", on a
hunch I renamed the definitions file to just "keys.cfg". And blamo,
the load procedure suddenly finds it and everything is peachy.
The upshot of this undocumented feature is that a malicious mod cannot
read the CD key off the filesystem and covertly transmit it. Gotta love
undocumented features...
2002.12.29 ~19 Objects in TinyScheme
Attempting GUI in Scheme. The easy way out is to translate the .menu
syntax into S-expressions. This gets sticky when it comes to widgets
performing special actions. In the TA menu system, special actions are
done through "script" actions, using keywords and commands interpreted
by the UI system. This means the set of actions that a menu item can
perform is limited by the commands recognized by the underlying C. And
even then, allows only simple sequences, no conditional nor looping
constructs.
I feel a replacement of the UI system is in order. I intend to use
Scheme as the implementation language for a new UI system, using an
object-oriented widgets set as in most modern GUI systems. I find
SDL_gui to be a useful scaffolding and template, as it is immature (less
code, easier to follow) and lacks the luxury of a preexisting "toolkit"
library (contains code for low-level input and output handling).
Researching OOP in Scheme led me to YASOS (Yet Another Scheme Object
System). While looking through and reading about yasos, I learned some
finer details about OOP and encapsulation, and just how badly C++
mangles the whole picture.
The problem at hand, though, is that TinyScheme can't support yasos
directly, lacking "define-syntax". SLIB can provide a working
"define-syntax" implementation, but I'm having a bitch of a time getting
SLIB to work in QuakeScheme. I could either try to get an almost-yasos
system going in QuakeScheme by whacking up some of the yasos code, or
try to get QuakeScheme to play nice with SLIB.
A yasos-less alternative is to use a different objects system. There
aren't a whole lot of those around. The author of TinyScheme has some
notes on a TinyScheme-specific object system, but (a) the resulting GUI
system would be implementation-specific, (b) the notes are "theoretical
ramblings".
In any case, having a working OOP system would help with widgets and
associated inheritances.
2002.12.25 ~12 Q3A bot files
The runtime files that reside in botfiles/. They munch ass. Seriously.
Mr Elusive ought to be hurt in a very painful manner for using such a
sadistic file syntax.
2002.12.20 ~23 Rise of the Triad GPL'd
Well, crap. RotT went GPL, and my hands are already full with the Q3
toolchain, two Q3 mods, and SMPEG.
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. Q3VM libc
* Implementation of Standard C Library for Q3VM bytecode.
* Implementation of a subset of Single Unix Specification v2 (SUS v2).
* Help import third-party library into Q3VM.
4. 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.
5. Q3 compilation toolchain
[X] q3lcc sources (official version out with Q3A SDK 1.32)
[X] q3asm - get static to work, dammit.
[ ] q3as - assemble-only (.asm to .o).
[ ] q3ld - link-only (.o/.a to .qvm).
5. 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