Some samples of various personal projects I have done. Note that these may be related to very odd projects, they were of interest to me, but may be of little interest to others. These may be useful to show some of my competence programming, and my knowledge of the APIs used to produce them. As these aren't really released programs, they tend to have a lot of debugging and test code in place; be prepared for high verbosity.
I make no guarentees that these will work on anyone else's system. I make no guarentees these will not damage anyone else's systems. I make no guarentees whatsoever about these projects.
I retain copyright on all code. You may download, unpack, and compile, but you are not permitted to retain code on a permanent basis. In many cases I may be willing to release this under GPL, but unless explicitly stated none of this available under GPL.
Fun with fractals, notably "Pascal's Pyramid" (hence the name). Pascal's Pyramid is very similar to the Serpinski Gasket (aka Pascal's Triangle), only 3D. There are four other fractals that are similar to this (the other platonic solids). Then there is a plant fractal, and some sphere tests. Select the above link for details and download.
XWing, a biological wing simulation program (originally bats, but bird wing motion is fairly similar). The theory is to generate a model which simulated the movement of animal's wings reasonably accurately and use the good animation in later projects.
The original theory was to create a simple animation test program, particularly comparing how the model looked with different parameters. The first piece of functionality needed was to simply be able to initialize a connection to an X-server and be able to draw stuff. Even without getting into drawing text this is not easy, though most of the individual Xlib functions are fairly well documented, there aren't any standard references as to exactly what steps are required. The method ended up mostly looking at what functions I needed to use (XOpenDisplay(), XCreateWindow(), XDrawSegments() and XFillRectangle()) and then working backwards towards what functions needed to be called to initialize the need structures. This is not easy, a good source rated this (specifically getting X initialized) as "moderate" difficulty.
Well, next challenge. Though setting changable values from the command line works, it is less than elegant. By contrast to Xlib's bad but available documentation, the commonly available Athena Widget's documentation is unavailable. Well, for a first pass, the olde text interface works. Not always to make work, after the case statement got over 300 lines it was pretty clear it was time to get that hoped for GUI in place. Still though it was getting over 300 lines of insanity the darn thing did work.
I'd liked the look of Tcl/Tk programs (or perhaps I should more properly say the look of the Tk library), so this seemed like something a possible method to use. A number of revisions later the Tcl/Tk front-end was in place and working... ...mostly. I found that the Tk library wants to control the processor, you're welcome to give it functions to call when it is idle, but it really doesn't want to let you have much control. After this, and other unpleasant experiences beating on Tcl/Tk to make them work as a front-end, I gave up. I think I am qualified to state that Tcl/Tk are a scripting language, and will never be much more than that; though useful for simple graphical stuff, it will never be much more than that.
Next candidate, the XForms library. Looked like a reasonable option, reasonable design tool, fairly reasonable interface. Good design in having the GUI description in a description format, rather than the C code it outputs. Then we to the next release of Debian. For my purposes it was pretty badly broken. I really didn't feel like spending a couple days figuring out the new magical incantations needed. Given certain other UI libraries coming to prominence, there were alternatives.
The two GUI libraries coming to prominence are GTK and Qt. Both are unlikely to have support of the community terminated any time soon. The documentation for GTK appeared to be in better shape (notably easier to find). Checking documentation, checking documentation some more, etc. Dummy UI building... Works great, time to test the hooks back to ensure I'll be able to glue it to the core of XWing, yet again, works great. Glued onto XWing, and it works pretty well. Though I didn't try every widget in GTK, I think I tried enough to get a decent overall feel for GTK; I found them to be very consistant amoungst themselves. I think I'll even have to categorize GTK as a pleasure to work with. They did a very nice design with GTK/GDK/Glib. So, due to GTK being very common, this is the version present below.
I've had some fun learning while building this model. I know how to simplify it (well, the controls anyway). I'm unsure when I'll be producing the next phase though.
The file is a conventional "tar"ed and "gzip"ed file. The Makefile has been tested on a Linux system, I strongly suspect it will work on most systems that have the required libraries. This requires GTK v2 for the UI, which you may have as part of GNOME 2. Most recent Linux distributions will install these libraries and have no problems, Solaris, FreeBSD and some Linux distributions will need to have GTK v2 explicitly installed. Once built, simply run it. The controls should be reasonably obvious; however, the final pair of sliders "bends" were reserved for future expansion and do nothing.
The bad ole days of the MU*s (Multi-User *). Before there was EverQuest and all the other MMORPGs, there were the MUDs, MUSHs, MUSEs, and MOOs. This was written on the grandfather of all MOOs (officially "MUD Object Oriented"), LambdaMOO. Looking back at this thing there are things I would change, but above all I can say the darn thing worked (if only after a fashion). After completion I asked for a quota increase on the MOO (hmm only 50K usable and this took half of that), and was granted. Due to the problems of its very large size (the bad ole days when a machine with 256MB of memory was really huge) getting quota on LambdaMOO was a significant accomplishment.
The language used was known as "LambdaMOO" (this was both the grandfather and origin of all MOOs). LambdaMOO was heavily object oriented and had an interesting design in order to be safe in a multi-user environment where most people were not programmers and users had to be able to run untrusted programs.
Unfortunatly this was designed to run on LambdaMOO, and most people may not have a server convenient. If used today it would also need a significant amount of work.
This was created to definitively explain RLE (Run-Length-Encoding) to someone. As these are examples don't expect them to compete with libraries like libz and libbz2. For specific instances they do work reasonably well though. This includes three RLE varients, plus an LZSS varient as a bonus.
This was created for compressing some ASCII art files. The ASCII art in question was some maps of AquaMOO. The maps in question had a lot of spaces in them, so it seemed worthwhile trying to shrink those. Well, spaces get RLEd and it noticably shrunk the files involved. Definitly not general purpose, but definitely effective in the target case.
Well, trying to explain RLE so we need a proper RLE implementation. This potencially does RLE on all of the input and provides a much better example of general RLE than the above. This is a varient though, it encodes sections of input with no runs with a length marker followed by the raw input. A pretty good example of RLE, demonstrating that in the general case, RLE isn't that great.
We need the final example of proper RLE with absolutely no contamination of modern optimizations. Well, this does that, everything is a run, often of only a single character. An example of pure RLE, demonstrating that in the general case, RLE really sucks; though in specific cases RLE is very useful.
Time for a compression algorithm of actual general use in the modern world. LZSS is a slightly tweaked varient of LZ77. This in turn uses something akin to LZSS. Might not be a proper LZSS implementation due to a few of the tweaks, but it is close enough to LZSS to be a varient at least.
The file is a conventional "tar"ed and "gzip"ed file. The Makefile should work on most Linux systems, and likely other systems that have the required libraries. To get good performance the tree implementation from Glib v2 is used, so Glib v2 is required. On Linux systems there is a good change Glib v2 is installed as part of GTK2/GNOME2, Solaris, FreeBSD, and some Linux distributions may need to have Glib explicitly installed. Once built these programs read from stdin and write to stdout. The "un" versions of these programs perform decompression.
Combinatorial search, wonderfully fun stuff. An inelegant solution to NP-complete problems, but one that produces useable results rather than nothing. One class of NP problems is graph coloring, so we have a sample graph coloring program.
Alas this is an example of overengineering. I ended up thinking about the future too much while writing the input portion, and time caught up on the search portion. As such this takes a lot of time to produce results better than a really stupid single pass. The theory was to have it do full LDS (Limited Discrepancy Search), I was trying to be efficient with memory (a crucial mistake when doing Combinatorial Search). With a fair amount of time looking at the code, it should in fact implement LDS without major changes (I believe it is close, but I'm not confident it in fact implements LDS).
There are still portions I feel are quite good though. In particular the loading of input is very solid (and hopefully bug free), throw some large chunks of concrete in its input and it won't have problems. The preprocessing and the data structure that input is loaded into are quite useful as well. This might also serve as a demonstration that I know C very well, by necessity the code is fairly complex.