Or just follow Amy Hoy's advice[0] and only raise the price for new customers. They probably could have bumped their prices by more than $1/month (and sooner) if they had taken that approach.
I did spend quite a bit of time on your site, linked sites, and webarchive. The files on your site did not work out of the box for me. I did eventually get a combination of kernel and configuration that kind of worked, but I think the CompactFlash card was too big. It stalled out on hard drive interrupts.
Ah, that's too bad! AFAIR zrafa's site[0] was the place to go for bootloader/kernel files specific to the 620LX/660LX, but the userland should work on any 6xx series.
I took eight years but I also got married, worked full time, and started a company before I finished. By the time I graduated, the CS department had started taking a much firmer stance on timelines, with a desire for most students to graduate within six years or sooner.
> It’s a slightly unusual implementation in that the surface of the game is, in effect, spherical – i.e. the edges are effectively a feature of the projection of the surface but left joins to right, top to bottom and so on.
I believe that is a torus, and not at all an unusual implementation choice for the Game of Life.
Yeah, I was wondering how they pulled a sphere off! (So I suspected it was just a flat torus instead -- for non-geometers, a flat torus is what the game Asteroids is played on. Unlike the usual embedding of a torus in 3D, the curvature of a flat torus is 0 everywhere.)
I think the only possible convex sphere made of squares is six nxn square grids stuck together into a big cube. Supposing n>=2, then there are 24 squares with the defect that they only have 7 neighbors. Flat tori don't have any defects, so game of life creatures can't locally measure they're not just in two-dimensional Euclidean space.
A wilder topology I've never seen the game of life take place on is 2d real projective space. Instead of just gluing bottom to top, side to side, you reverse the orientation as you glue. So, if your Asteroids spaceship is flying upward near the left side of the screen, when it goes past the top edge it would appear at the bottom edge flying upward near the right side of the screen. You could also play on a Klein bottle by reversing only one of the orientations.
This article does not cite any references (and is from 2010) so I can't tell if the author was aware that packrat parsing can support left recursion (PDF, 2008): http://web.cs.ucla.edu/~todd/research/pepm08.pdf
Also worth noting from this paper is this, which is an underappreciated facet of packrat parsing:
> It should
be noted that while Packrat parsing obviously adds an extra layer of complexity over ‘pure’ PEGs, contrary to expectations it often slows parsing down when used blindly
for every rule.
Especially these days, and really definitely in a lot of dynamic languages (cfe Ruby), the kind of allocation rate that packrat parsing produces has a significantly negative effect on performance. Applied blindly you're just trading n^2 performance for n^2 memory use, and that may not work out the way you think it should.
Actually performance is exponential without memoization, so usually some amount of memoization is essential, but memoizing more rules usually does not help.
