My Favorite New WebKit Bug!
2010.05.07 in code
Watch the window decorations!
HTML5 video below; will only work with very recent browsers. Otherwise, here!
hortont · blog · code
Horton Slab Writeup
2010.05.07 in code, school, and typography
Introduction
Don't expect this to be anything... it's just a bunch of relatively-disconnected words about what was going through my head at various times during the project, and how I fixed it, which I'm writing at the request of the professor. More or less...
Glyph shape
Each glyph is a Python class which, when instantiated, knows the properties of the glyph (weight, cap-height, slant, etc.). Using this information, it constructs the geometry of the glyph, which is made by combining two different primitives: line and circle. Both of these primitives can also be clipped by arbitrary polygons (this is how the C is constructed, for example: by taking a circle and clipping out a triangular wedge from it).
Geometry manipulation (basic boolean stuff; almost always either union, intersection, or difference) is done with the Shapely library, because I really didn't want to do that myself, as it's not very interesting.
Each glyph has a function which calculates its width relative to one em, information which is used heavily during the drawing phase.
The glyph shape function can be either very complicated (like, say, 2) or very simple, like that of the lowercase l:
mainLine = Line(self.p(0.5, 1.0), self.p(0.5, 0.0),
self.weight(), serif=5)
return [mainLine]That's a very simple one. 2, in comparison, is about 50 lines long...
The line constructor that you see above takes three required arguments: the location of both endpoints, and the weight of the line to be drawn. The optional serif argument adds serifs, which we'll talk about later.
The 'p' function (I needed a really short name because I call it hundreds of times and wanted it to be neat - think of it as 'position') that I call there takes a percentage position (0.0 to 1.0) in x and y (measured from the bottom left, like things should be done) and turns it into coordinates in the glyph's coordinate space. p also takes another argument which determines whether it should consider the top of the glyph to be at the cap-height or the x-height.
Many of the glyphs have small adjustments that are made to the shape of the glyph as the weight changes, in order to correct for unpleasant effects.
So, the l above makes a line from the top, halfway across the glyph, to the bottom, halfway across the glyph, at the full weight of the glyph, with the 5th serif type, which will be described below.
You can look at the rest of the glyph functions on GitHub: Capitals, lowercase, numerals, punctuation.
Strange or Missing Glyphs
I added center-dot (for multiplication) and interrobang (at the request of my roommates) to the normal set of glyphs. My 0 is too wide, but I couldn't bring myself to make it an oval (or, more likely, similar to the shape of the 6 or 9). My angle-brackets are huge. HUGE! Maybe I'll fix them someday. I'm missing curly braces, because they'd be really annoying to draw. Much worse than 2, which was enough of a pain that I don't want to endure it again.
Serifs
Serifs are actually added by the line drawing logic - each character doesn't really need to know how to draw a serif, it just needs to know what kind of serif it wants, and asks politely for that. There are 6 kinds of serifs a glyph can ask for on one of its lines:
0 - No serifs
1 - A vertical half serif on one end of the line. (E)
2 - A vertical half serif on both ends of the line. (T)
3 - A full serif on one end of the line. (A)
4 - A full serif on both ends of the line. (H)
5 - A full serif on one end of the line, a half serif on the other. (l)
6 - A half serif on one end of the line. (j)The fact that glyphs don't know about serifs is neat, because it means we can turn off the serifs very easily, by just asking Line not to draw any! That's how we get the sans-serif variant, which isn't on the poster, but that's ok... it's just not as awesome.
Properties
PHI = 1.618... (golden ratio)
Fixed glyph properties are as follows:
1 em = capHeight / PHI
xHeight = capHeight / PHIThe defaults for variable glyph properties are as follows:
weight = 3 (this is a unitless measure, where ultralight = 0.5 and heavy = 7)
slanted = False (not really italic, it's more slanted than anything)
outlined = False (this was more for testing, but turned it into outlines)
color = Black (obvious)
serifed = True (whether or not Line should draw serifs for this glyph)
autoKern = True (you'll see, in a bit)Italic
The italic variant isn't nearly as neat as all the rest, it's just made quite literally by shearing the character with Cairo while it's being drawn. Not interesting, not particularly awesome, but it worked out OK. There's a pretty good chance it will break the consistency of inter-word spacing, but I'm not totally sure how to fix that (without doing the shearing beforehand, with Shapely... or manually).
Weights
Technically, you can generate glyphs of whatever weight you want, because it's all procedurally generated. However, I blessed a few weights so that I didn't have to look at/tweak more than a few weights:
Ultralight = 0.5
Light = 2.0
Regular = 3.0
Bold = 5.0
Heavy = 7.0Kerning
Kerning was a stickling point for the first few days. At that point, I was just throwing glyphs down and advancing the x position by the reported width of the glyph. We all know why this doesn't work, though, with the AV pair being the classic example.
So, instead, I wrote an optical autokerner in a few lines of Python. It works by placing the two glyphs on a plane and shifting them back and forth until it finds the boundary where they're just touching, then adds the correct amount of kerning. There's a kerning table which gives adjustments relative to this value, but it only has a handful of entries (one case which was particularly problematic was +=, where the bar of the plus slid directly into the middle slot of the equal-sign, kerning them way too tightly). It could probably do with a few entries, but after all this, I didn't have a lot of time to work on the kerning table, and I didn't really think it looked terrible - at least not enough to worry about.
There's another issue with the optical autokerning: punctuation. Tiny little dots don't autokern well at all; also, quotes don't ever collide with lowercase letters, so that breaks things too... So I added a per-glyph override which instead kerns based on the bounding box of the glyph extended to basically-infinity in the vertical direction. This mostly fixes the problems with punctuation.
The autokerner is really quite slow (as you might expect), especially for large blocks of text, so there's a disk-based cache that stores the kerning values between runs. You have to delete it if you change the glyph shape, or your kerning will be horribly wrong. Also, the cache is per-capHeight-per-weight (as kerning values change slightly), so if you change the capHeight or weight, get ready to wait again...
Layout
The space character is also a glyph - it's a square block which is special-cased to not be drawn at all in the drawing logic. This fixed a lot of trouble I was having when advancing words in the "stupid" way (just adding some amount of x-advance each time you see a space character), where the space between the words ended up varying significantly, which was really tripping up reading.
My line-breaking algorithm is horribly primitive: it just draws words at a time; when it gets to each word, it checks to see if it's past the edge of the layout box. If it is, it moves down by the leading and moves back to the left side of the box. This is a problem mostly because it means the last word on a line could be (and usually is) extending beyond the right side of the layout box. Also, it creates really crappy right rag unless you pay a lot of attention, because it's really not aware of the idea of rag.
If I had a ton more time, I'd implement Knuth's famous line-breaking algorithm (the one TeX uses), which is pretty much ideal, but since I don't have that kind of time, I decided against writing a poor knockoff. I've heard it's not actually that complicated, but... relative terms...
Input Format
The main program takes an XML file with a very simple format. For example, you can see the one that makes the description of the various weights that's on the poster here.
There are only a few tags defined:
u, l, r, b, h = Weight (ultralight, light, regular, bold, heavy)
i = Slanted/Italic
br = Newline
textbox (attributes x, y, size, width, height) = A reflowing text container
leading, tracking, size (attribute px) = Obvious text properties
color (attributes r, g, b, a) = Obvious color properties
sans, serif = Turn on/off serifsMore Stuff
If you have any questions, feel free to email me.
The code is all open-source, under the relatively permissive 2-clause BSD license, which basically just says you can do what you want with it as long as you keep my copyright header around... (the terms are in LICENSE in the source directory, but they're exactly the same as all of the gazillions of other BSD projects out there). The code is here.
Libraries/Thanks
Python
GEOS + Shapely
Cairo + PyCairo
ElementTree
Orbitals, Particles, a Font, and some Sheeple
2010.04.29 in code, school, and typography
Apparently the semester's nearly over, or so I've been told (repeatedly. naggingly.)! In any case, I've gotten a lot more done on some things than I expected, and a lot less on others... it's always hard to predict how the semester will go.
A Font
For Typography, I've been working on the font + renderer + autokerner that I just wrote about the other day. I won't post any more pictures, just scroll down a little further to see that post!
Orbitals
For Parallel Programming, I've been working on a atomic orbital simulation, using OpenCL to evaluate the electron probability density function for a hydrogen atom at many, many points. It makes nice smooth images like this:
It's showing approximately a 20x speedup, moving from Zoe's CPU to GPU (Core i7 @ 2x2.66/3.33GHz to a NVIDIA GeForce 330M GT). The move from Zoe's CPU to Jayne's GPU (the 4890) is even more awesome; it's something like 40x faster!
Eventually (soon), I'm going to make an animation with it, and then it's time to write a paper!
Particles
For Advanced Computer Graphics, I've been working on a particle system simulator that uses (surprise!) OpenCL to simulate tons and tons of particles at once (millions, anyway). And render them, attractively (the renderer is still in its infancy). And it comes with a tool to design them, too (also incomplete).
I don't have any really interesting examples to show now, because I just got emitters to work. Below is a picture of something like 1,000,000 particles being blown away from the origin by two "simple"-type forces (they just push outward from a point, with inverse-square falloff).
And a video (which will only work if you're using a very recent Chrome or Safari, probably) of the same simulation, though with only 128K points. This simulation really isn't interesting because there's nothing complicated going on. I've got gravity working, which is a gazillion times more interesting and more complicated, but I'll post pictures and video of that some other day (it's also much, much slower).
It also turns out that the overhead of OpenCL isn't worth it for simple forces; it significantly speeds up complex (O(n^2)) forces like gravity (I'm aware of many ways to speed up n-body simulation, I just haven't had a chance to implement them yet), but for O(n) forces like below, it really only provides a tiny-to-near-zero gain.
Sheeple
All of this (plus normal coursework) leaves less time than desired for other things, but I still manage to occasionally put a few hours in to work on Sheeple. I feel bad that I don't have tons of time for RCOS work, though I will note that all of these projects are open source (all of them are under the 2-clause BSD license except Sheeple, which is GPLv3), so the general idea of promoting/using/writing OSS is still there :-)
I recently wrote and pushed a partial implementation of a Google Contacts backend for Sheeple. It's a lot smaller (and nicer, since it's written in Vala), and it's what I'd like to use for the time being while developing the UI and backend stuff, since it's a lot easier to change.
Another thing that contributes to slow Sheeple development is that everything now takes place in a VM; I don't have a native Linux install anymore, and I consider that a good thing. I've gotten sick of wasting time with a broken system, and I'm just not going to do that anymore - I don't care enough nor have enough time to spend to fix things, and I'm just generally all-around much happier in OS X. So both of my machines are running OS X, and I'm pretty sure that's how it's going to stay for the foreseeable future.
I should thank Moorthy and Sean O'Sullivan for putting up with me, and for constructing RCOS and keeping it alive. I wrote a long bit about what I think about RCOS and the people involved a few months ago, and that all still stands. Given this semester's overload (which will likely continue next semester) and how RCOS has worked out within this semester, I find it somewhat likely that I'm not going to participate next semester; I feel guilty about being paid to do much less work than I feel like I should be doing. I'll still hang around, certainly, and I'll (obviously) still write OSS, I'll even happily talk about stuff I'm working on, but the absence of that feeling of guilt/obligation/deadline (and also the ability to bounce between projects as I feel like it) will be quite the load off.
Slow Transition to S3
2010.03.07 in code and personal
I finished another part of my slow transition away from Dreamhost and on to Amazon's S3 for this site last night: I deleted everything related to this domain from Dreamhost. This meant setting up the Google App Engine proxy I've been thinking about for a while (which ended up being a just slight bit of horrific hackery upon shrub), and moving my DNS stuff back to the much-less-flexible 1and1 servers (which I get for free with my registration). This is a really ugly solution, because it adds another bounce for all HTML pages, but it still seems to be faster than Dreamhost, somehow.
It's mostly all working - unfortunately, GAE apps can't run on a naked domain, so the www is required now - any links to a subdirectory of hortont.com will redirect to the toplevel page. But I decided the temporary inconvenience was well worth the ~10$/month savings, so that's OK.
Also, links from more than 8-10 months ago are completely invalid now (I had a bunch of redirects, before, but they're gone now too in the shuffle). But that's OK, too. Really, who keeps around links to my blog? All of the internal links should be valid... I guess the big issue is things subscribed to RSS feeds with the naked domain. (I've already fixed a few random things I've found with this... I should check on Planet Gnome and stuff, too...)
I just have to move Carol and Matt, and then everything will be great - I've spent less than a dollar over the course of 2 months or so of S3... excellent!
I expect to find things broken over the course of the next few days... if anyone else runs into anything, let me know!
The proxy code is on Github.
Sheeple, One Semester In
2010.02.26 in code
Last semester, during RCOS, I started working on a contact-management application for GNOME (Seed is mostly in maintenance mode, at this point), called (for lack of a better name, at the moment) Sheeple. I keep a carefully-organized, constantly-updated address book, so I spend a bit of time in whatever contact-management program I'm using, so this is something that matters a good bit to me personally.
The de-facto application for managing contacts on GNOME at the moment is, of course, the behemoth personal-information-management suite, Evolution. Evolution has a long history, and is a large codebase, written by a lot of people, over a very long time. It also looks a little bit outdated:
Not a pretty sight. Not to me, anyway, not in 2010, when my alternative is:
Another fundamental difference between the two is in their editing functionality. Address Book provides the ability to edit contacts inline; Evolution requires you to edit contact information in an overly-limited (while it can store more than four email addresses per contact, you can only edit four in the editor window... what!?) separate window.
I decided to start working on a more Address Book-like application for GNOME. After a bit of deliberation, I decided to have it backed by Evolution's evolution-data-server, so that people's contacts would transition over smoothly. This might have been a mistake, because the EDS API isn't beautiful, and there are very few complete, working bindings, but I've made it mostly work.
It's written (mostly - the EDS-related code is straight C, unfortunately) in Vala. It's my first Vala program, so it's been a learning experience — Vala seems nice, though there are a few bugs (I've reported one glaring bug which was acknowledged, though it hasn't been fixed yet), and some bindings are a little sketchy.
During the development, I discovered that Nokia was developing libosso-abook (for Maemo), an address book library that provides a lot of the functionality that I was planning for libsheeple. Unfortunately, libosso-abook is currently closed-source. Not cool, Nokia... Anyway, if they open-source it (it's under consideration, at the moment), I'll probably ditch most of libsheeple and base the Sheeple UI on top of that, because it's a ton of annoying code already done.
After the end of last semester, I had the following:
Lots of things are broken, but it's something. I don't have working syncing yet, and I believe writing back to EDS is broken at the moment (so no persistence of changes!), but those are things I plan on working on this semester...
There are slides and stuff available, too.
A Move to GitHub
2010.01.18 in code
I decided that hosting my Git repos on Jayne was a silly idea. While it did mean nearly infinite storage (and upgrades at a fraction of the price of any alternative) and incredibly fast clones/pushes, having to deal with repository downtime every time I move my computer or decide to start Windows to play a game is simply ridiculous.
So, I've moved everything to GitHub. One visiting my Github profile should keep in mind that a lot of the stuff there wasn't public before, and 90% of it is stuff that got about 1% of the way done and was abandoned, or stuff which is years old at this point. Therefore, browsing around there is not recommended. However, from now on when I reference projects, I'll link to GitHub (and I'll probably go back and update old links in my blog, too).
Interesting repositories include the one for this site; my old GMP+GD mandelbrot generator; Sheeple, the Gtk contact management app I've been working on for RCOS; and the code behind my web-based Aperture tag browser.
ICC and Mandelbrot
2010.01.04 in code
About a year ago, I implemented a smooth-coloring Mandelbrot generator in C on top of GMP (for high precision and speed) and GD (for image output). I spent a lot of time choosing GCC optimization options and hand-optimizing the code (let's play how-few-GMP-instructions-can-we-use), primarily as an exercise. It ended up many times faster than the original, and I eventually ran out of ideas and got bored with the optimization and set it down. It's still the most carefully crafted and most commented piece of code I've ever written, and produces output like this:
I've been hearing a lot about ICC, the Intel C/C++ Compiler, recently — especially how much better it is at optimization of math-heavy routines when compared to GCC. I generally refused to believe people when they claimed 30-50% speedups, if only because it seemed like simple hyperbole.
I downloaded an entire gigabyte worth of compiler (WHAT!) yesterday and set to do some tests using my Mandelbrot generator. I took some time to rebuild GD and GMP with each of my test compilers (ICC 11.1, GCC 4.2, LLVM-GCC 4.2, and GCC 4.5 — unfortunately I couldn't get GMP to build with clang), and then sat around with the manuals correcting optimization and build arguments for each compiler. I then took the average of 10 runs of the program (all runs ended up being ±2% for any given compiler), and came up with the following:
Holy crap... a 2x speedup! Crazy crazy stuff! I realize that this is a completely unreasonable benchmark, performed under less than perfect benchmarking situations (though they were pretty good), and is not representative of "normal" code, and should not be used to pass judgement against any of the involved compilers, but it's relatively representative of the kind of code that I want to run fast. I've had long-running math-heavy programs in the past which I would have been very happy to have been able to speed up anywhere near 2x (in order to meet class project deadlines...)!
I also find it funny that ICC produces both the fastest and smallest code, and that turning on profile-guided-optimization had no perceptible effect (except, obviously, to make the compile time ridiculous). I presume this is not the case in other scenarios.
ICC seems to also have better static analysis (it's pointed out a few legitimate warnings in the code that neither GCC nor LLVM-GCC nor clang picked out). But I guess that's what happens when you've got billions of dollars to throw around...
I should also note that all tests were done on the 2.4 GHz Core 2 Duo T7700 in my 2007-era MacBook Pro. A chip that Intel knows how to optimize for, apparently!
One more for your viewing pleasure (this is a zoom quite deep into the set, Wikipedia copy):
NOTE: Dad suggested that the 2x speedup might be due to autoparallelization or some such. However, luckily for my benchmark, this is not the case, as the program already takes advantage of both cores (spawning 10 threads each generating a tenth of the image), and manages to consume ~197% of the total CPU time (across two cores) over its lifetime.
Seed on Mac OS X
2010.01.02 in code and gnome
New Year
First things first, happy new years! I'd say 2009 was one of the better years, personally (the world on a whole might have something to say about this), but I'm shooting for even more fun during this orbit.
My Gnome Stuff
I'm home from school until almost the end of January, and all of the holidays are over now, so I have a great deal of time opening up to work on various things that I've promised everyone. I apologize for disappearing, but school got particularly time-consuming last semester (and the time I spent on it resulted in my best semester yet!) — and that comes first.
Seed on OS X
Over the past few days, I've been getting Seed working on Mac OS X, in order to (try) to decrease the number of brain context switches required when I want to work on something quickly (I spend 99% of my time in OS X).
I've now got MacPorts packages for gobject-introspection, gir-repository, gnome-js-common, and seed, as well as modified packages for webkit-gtk (to fix a bug in the current packaging), clutter/clutter-gtk (to enable introspection support), and gnome-common (to pull in gnome-autogen.sh from 2.28, which works with the version of automake/autoconf that currently ships with MacPorts).
As far as I know, these packages only work against the very latest version of MacPorts (1.8.1), with the very latest packages on an install of Snow Leopard with 64-bit-userland (I suppose the number of people with 32-bit-Snow-Leopard is rather low). I've tested it from a totally fresh MacPorts install twice now, and it seems to work fine.
It's relatively easy to install, with one caveat: I don't have a machine which is both online most of the time and I have the ability to run rsyncd on, so you'll have to manually pull changes (I'll explain how in a moment).
To install:
-
Check out my custom ports tree:
cd /opt sudo mkdir hortont-ports sudo chown [your username] hortont-ports git clone http://www.hortont.com/hortont-ports.git
- Edit the file
/opt/local/etc/macports/sources.conf
with administrator privileges, and add the line:
file:///opt/hortont-ports
before the line (at the bottom of the file) that reads:
rsync://rsync.macports.org/release/ports/ [default]
-
Upgrade your currently installed ports (important!), then install seed:
sudo port sync sudo port upgrade outdated sudo port install seed
-
Update your checkout of my ports tree:
cd /opt/hortont-ports git pull
-
Update your installed ports:
sudo port sync sudo port upgrade outdated
(this all also assumes that /opt/local/bin is in your PATH):
-
export LD_LIBRARY_PATH=/opt/local/lib
-
seed
One of the primary things I'm planning on working on over the next few weeks is getting the three games from the summer up to tip-top shape for 2.30. Lights Off and Same (now swell-foop) are shipping, but they need documentation, high-scores, and (especially in the case of Same) performance help.
Epiphany Extensions
I've just gotten word that Epiphany JavaScript extensions are working much better now, as of the most recent (today) release of Seed. The last time I promised to look at various extensions for people, stability was a problem to the extent that I gave up after about ten minutes. So, this is another target for the next few weeks. Port some extensions, write some documentation, post the one extension that we have that works well somewhere better than bugzilla, etc.
All in all... should be a fun few weeks vacation!
Would You Like Some Python With That?
2009.11.21 in code and personal
If you're actually *crazy*, you might have noticed that the design of this page changed a bit about a week ago. This isn't because I've been tweaking my WordPress theme — I got sick of that a long time ago. No, instead, I replaced this all with a solution much more amenable to my own mindset; a completely-statically-generated, git-backed, python-based blog. It's not an interesting project in and of itself; every programmer writes blog software at least once in their early life (and this is poorly-written, just like most of them!).
It's really only interesting in that I'll note that only the RSS2 feeds will work from now on; no more Atom/RSS 0.9, because I don't care enough. RSS feeds are the archive page url (for the main archive or any category) + "/feed", just like before.
With that said, this is my first post entirely with the new system, so hopefully everything will go smoothly! I get to test it locally, then 'git push' and whoosh! magic jumps to Jayne and then off to Dreamhost.
On RCOS (or, Open Software at Rensselaer)
2009.11.11 in code, gnome, school, and summer of code
Excuses
This post has been stewing for a very long time, as is evidenced by it covering a span of three years. With such a long timeframe comes a terribly scattered and disconnected process of storytelling (for me, at least), so keep that in mind while you notice how long your scrollbar currently is... there is no structure here, only late-night babble.
Also, I apologize in advance for making anyone feel bad over the course of the next few paragraphs...
The Problem
A freshman's eye would peg Rensselaer as a paragon of proprietary software, and they certainly wouldn't be wrong. A majority of the academic portion of campus is heavily entrenched in software like Office, MATLAB, Mathematica, and various CAD packages (or Creative Suite, Max/MSP, and Final Cut Studio, on the other side of campus). I wouldn't blame this on the 'tute, though — many of these packages have no free/open source counterpart even remotely in the same tier. The problem centers more around how much the attitude that comes along with such software is also pervasive here.
Going to RPI — for most people (mainly the engineers and artists, who together comprise way more than half of the student body) — is about spending four years learning how to make lots and lots of money using the tools that you have to use in your particularly overspecialized field; nothing more, nothing less. There's been a recent push for multidisciplinary studies, but I feel like this isn't as serious as it could be, yet — destroying entire departments (foreign language, for example) doesn't lead to much faith in this program...
While this heavily money-and-proprietary-software-driven philosophy might be a little off-putting to someone coming from a background filled with free and open source software (or even a science-for-science's sake background), there is hope!; this is what I want to write about, since it's much more interesting than what's broken...
The Real Problem
I should first clarify that I don't have a problem with proprietary software; I use OS X as my primary operating system, I often resort to Mathematica or Final Cut to do things that can't be easily solved otherwise... I'm very much a right-tool-for-the-job person. My problem is with the attitude; the attitude that says that "everything I create should be mine because there's a chance I can make fame or fortune off of it, and why in the world would I want to share that with other people?"... that is the attitude driven by total immersion in a corporate-academic/closed-source world, and that is what I have a problem with, and it's deeply embedded within both the faculty and a significant portion of the student population.
During freshman year, I spent the whole year doing physics and hiding my disapproval for the overarching RPI philosophy by spending lots of time with my few dozen extremely social floormates. Robb and I often chatted about how we felt about the school, and supported each other as much as we could in terms of not following in everyone else's footsteps.
By the beginning of sophomore year, Robb and I had heard rumors from one of our CS professors (Robert Ingalls, who taught our operating systems course) that there was actually a forming contingent of like-minded folk — people who enjoyed writing software in order to share it with the world, people who believed in the world we believed in.
Finding RCOS
This group turned out to be the Rensselaer Center for Open Software (RCOS, as we semi-lovingly call it). Headed by Moorthy (who was also my data structures professor at the time, though I didn't make the connection until mere minutes before we met him to propose our project), RCOS is an interesting beast. It provides funding, support, and — more importantly, at least in my opinion — a home for people interested in working on or learning about free/open software.
In order to participate, you have to bring a project to the table. It could be something small, as you're just getting started with programming, or something grand, far beyond the scope of a single person project, something you just want to peck away at — as long as there's something to be done, and you're willing to share your code and ideas, you're welcome to stay as long as you'd like.
Three times a semester, the group (or individual) hacking away at each project has to get up in front of the rest of the group — which now numbers somewhere around 30 — and show off what they've done, where they've come from, and where they hope to go; these presentations take place at weekly meetings which form the primary social interaction of the group and provide a place for people to bounce ideas off everyone, show off what they've learned, and get support from the rest of the group when they're having an issue.
Seed
First semester sophomore year — shortly after we discovered RCOS — Robb, Matt, and I proposed the "Orange Window Manager", a next-generation window manager that we were planning to write, utilizing Robb's knowledge from his time working on Compiz, as well as various technologies not then being used in window managers (primarily, Clutter). We wrote Seed, the JavaScriptCore<->GObject-Introspection bridge which we were planning to use for extensibility within our window manager, instead, mostly after realizing that we didn't have the time nor patience to write a window manager. Hearing about Shell and Mutter and friends at GNOME Summit affected that decision a slight bit as well; we had already accidentally duplicated some of the effort in creating Seed alongside GJS, we weren't interested in continuing down that path.
RCOS ended up funding two semesters of Seed development and also provided a place for us to show off what we were working on to a bunch of people from outside of the GNOME developer community — which is really a great thing, and lets you put a little bit of perspective on what you're working on... both semesters we had other overarching projects in mind, but both semesters Seed was the primary target of our development time, because it was something feasible and something potentially useful to others.
Big Picture
Without something like RCOS, Seed almost certainly would not have been written; I would still be sitting here having never gotten my hands dirty in the GNOME world (some would say we'd be better off that way :-D); and, more importantly for the big picture, dozens of undergrads would never have gotten a taste of community in software, nor of writing code out in the open, nor of thinking of themselves second for once when coming up with ideas.
I believe that this is incredibly important, and — shockingly — something relatively unique to our campus (I realize it happens in other places, but not nearly as many as one would initially hope), and that more campuses should take heed and — if at all possible — try to pull off something similar!
The Man with The Plan
It turns out that this is all made possible by one person: Sean O'Sullivan, who graduated from RPI in '85 and went on to help found MapInfo — far from being a model citizen of the free/open-source world, but the timeframe excuses them, without question.
Mr. O'Sullivan apparently believes in our world too — so much that he donated a significant chunk of money in order to initiate and fund RCOS for a few years, as well as to create a annual semester-long course on developing open source software (which Robb is currently enrolled in, and is having a blast with, from what I hear...).
Reasonable social protocol would dictate that Seed contain some sort of "thank you" to both Mr. O'Sullivan and to Moorthy; unfortunately I never quite feel comfortable inserting any sort of message to that effect anywhere, nor bringing it up this late in the game, so this is my thank you: thank you for the last three semesters, and hopefully three more; thank you for believing in our cause and our world; and thank you for showing even just a few new people something they hadn't seen before, and possibly wouldn't have had their paths not crossed yours.
TL;DR
RPI has an awesome-but-underappreciated program for getting people involved in open software, run by Mukkai Krishnamoorthy and created by Sean O'Sullivan, and it gives me the little bit of hope I have for our community...