Archive for the 'Development' Category
I’ve updated Toppler to a universal binary, using the same source tree as the previous 1.1.1-1 version. This, unfortunately, requires it to be run under 10.4.x. If you’re still running 10.2.x or 10.3.x, you can still download the previous PPC version (works great under Rosetta as well) from the same page, just under the main download link.
One quick thing to note - if you have any high score files left over from a PPC->Intel conversion, these won’t read properly with this version. The high-score code is very endian dependent, and I didn’t update it to properly handle all cases. No biggie, but if you see some strange high scores in there, get rid of your /Users/
I’m getting ready to post new binaries for Fillets and Freedroid as well, so stay tuned.
Update: One more update to 1.1.3-4 to include some language fixes and new levels. Check the toppler page for details.
Yet another version of Tower Toppler, version 1.1.1 was releases by Andreas Röver. This comes quickly on the heels of the 1.1.0 version. The main changes are:
- Included Pasis 2 Towers
- New Finnish translation
- Updated French Translation
I’ve updated the OS X packages on my Toppler page. Worth a download for the new level set!
Update, December 24, 2004: The issue with Toppler not running on 10.2.8 systems has been fixed. It was due to a missing function in the 10.2 C libs. The new version is 1.1.1-1
Andreas Röver has released a new version of the Tower Toppler source code, 1.1.0. The basic changes are:
- Joystick support (though I have no way of testing this…)
- In the level designer, elevators can now be made to pass doors
- There was a condition where the little green guy could get stuck
- A Windows bug with a strange .dll was fixed (not that this affects you Mac users)
I’ve updated the OS X packages on my Toppler page, though this update for Mac users probably isn’t that big a deal.
This article from the New Scientist print edition has a small interview with Benoit Mandelbrot. If you don’t know who he is, you need to turn in your Geek Credential card at the door, please. A small excerpt:
Q: Even though most people view it as a beautiful image and ignore the underlying mathematics?
A: That’s right. Yet there is nothing more to this than a simple iterative formula. It is so simple that most children can program their home computers to produce the Mandelbrot set.
I thought that this was pretty funny. When I first got my hands on a C compiler for my lowly Commodore 64, one of the first things I did was to try and build a program to display the Mandelbrot Set. Previously I had taken his book, The Fractal Geometry of Nature out of the library (I later purchased a copy.) I wanted to write some software to generate the set, but my meagre computing resources limited my language selection (let’s see - assembly or BASIC…)
I even wrote a letter to Mr. Mandelbrot on a sheet of notebook paper asking what language he used to write in (among other questions.) He replied, and I still have the letter in my files. It contained a signed hand written note saying he used FORTRAN as his language of choice, and he included some photocopied sheets giving some implementation details and hints. I was 13 at the time, and I was in heaven. Yes, other people may have written letters to pop stars. I wrote to a mathematician working at IBM’s research labs.
But I eventually found a C compiler (Abacus C) and began writing, translating the formulas found in the book into what was, looking back on it, poorly crafted C code. The result? After some debugging and letting my little program run for nine hours, I had a simple monochrome 320×200 representation of the Mandelbrot set on my screen, red on black. Later revisions added the color gradients you see on so many versions of the set, though I was limited here to four colors and this halved the horizontal resolution. I even was able to add a simple zoom function. But with nine hours between selections, I didn’t go very deep.
A few years later I got my first PC, and one of the first things I did was buy Borland’s Turbo C and move over my Mandelbrot program. Somehow, it wasn’t quite the same. I could watch in real time the whole set being generated on the screen. Many more colors available. Zoom was even practical and useful. Just didn’t have the feeling of anticipation that the 1Mhz C64 generated as you watched, pixel by pixel, the set being drawn.
Ah, yes, the good old days.
Here is a great little page that gives a whole pile of small sed scripts for all kinds of random tasks. This is a great quick reference for all those who don’t use sed enough to remember it’s arcane syntax.
If you don’t know what sed is, feel free to ignore this.
Some of you may remember many hours
wasted spent playing a game on C64 or similar called Tower Toppler, aka, Nebulous. Well, for some time now, Andreas Röver has had a port of this game available as free software. I’ve in turn ported this to OS X for everyone’s enjoyment. You can download the .dmg file from here.
There seem to be two separate theories or good software design that everyone seems to espouse:
1. Write good software to begin with, then hope it doesn’t fail. This is the putting all your eggs in one basket theory, after making sure you’ve built a really good basket.
2. Write software, assume that it will fail, but make sure there is some redundancy in the system. Ensure it restarts when it fails, make sure there are two machines to handle the job, etc.
There are three assumptions that I hate about these all-too-common paradigms.
1. This assumes that you can write software that doesn’t have any faults. This is demonstrably false. This theory is often espoused by younger programmers and the ideologues in your group. Beware.
2. This assumes that you can’t write software. Nothing wrong with this, given number one above. However, this leads directly to the conclusion that any old crap will work and that testing, quality don’t matter. This is often espoused by older programmers and managers under time pressure.
3. Oh — the third assumption that I hate? The fact that these two options are the only way.
Me I prefer a third paradigm: Combine one and two. Make sure you write the best stuff AND provide a backup. Duh. Let me tell you how this wasted nearly my entire weekend:
I work in a small software shop. We have a part time MIS guy who works full time programming for us. He’s pretty good. Unfortunately, he’s out of town at a tennis tournament in Vail. That means that I am the designated sufferer this weekend.
We’ve almost divested ourselves of all of all our Windows servers. We still have one, required for our CRM system, that runs MS SQL server. From this server, we serve data to lots of places: inventory management, sales reports, etc. We do this from other Linux servers, running Perl and PHP scripts accessing the SQL server through a ODBC connector, running on the NT box. This works well, except when it doesn’t.
This ODBC Connector (hereafter referred to as That Piece of Shit or TPoS) runs as a service on the NT box. Here is where the design theories come in. Both the developer of the service and Microsoft fell prey to design fallacy number one above. That nothing would go wrong. TPoS developer thought that their little software would run forever, and provided no way of monitoring it or easily shutting it down remotely. Unfortunately, Microsoft also assumed that the software running as services on their machines would run forever. And they too provided no easily accessible way of restarting or maintaining things remotely. This means that when something goes wrong - someone has to go sit at the console and make changes. Restart TPoS. This wasted my weekend, as this happened (for no obvious reasons) three times this weekend.
IMHO, this is one of the number one reasons that MS servers are unsuitable for use in business. They require too much jiggery-pokery to run well. Yes - their are solutions to the above problems: running VNC (over a secure VPN - another thing to set up and maintain!), some remote access tools (buy them as extras!) These solutions suck just as much as trying to get my Mom to run Linux on her desktop. This leads to lesson number two for the weekend: Use the right tools for the job.
If Linux worked on the desktop, then it wouldn’t need so much hacking and *censored*ing around as it does to play well with others. It’s getting better, but it isn’t there yet. Don’t cry to me. But for this same reason, Windows isn’t ready for the server room. Just too much hacking to get it to work. Use the right tool for the job.
Of course, I’m saying this as I type in a Starbucks on the third option - OS X. Sosumi.
ccache has changed my life. I happened upon it while browsing Freshmeat. What is it? ccache caches object file output from your compiler and keeps it around across makes. When compiling the same file again, instead of going through the preprocess/compile thing again, the object file is simply supplied as the output from the compiler, speeding future builds 5-6 times. A user mode linux kernel make now runs in 20 seconds, versus 10 minutes.