If you use Perl at all, how about taking the Perl Survey 2007? They’re collecting results until September 30th. After that the results of the survey will be freely available. They’re trying to answer some basic question about the Perl Community like how many people use Perl as a primary language; how many Perl users participate in mailing lists, user groups, conferences; and what other languages are used by programmers who use Perl.
I was driving home from work recently after a particularly stressful day when some random synapses fired in my brain (or perhaps just burned out from stress) and an idea formed.
Standard diatonic musical scales have eight notes, a power of 2 that can be represented by a 3 bits. We’re used to thinking of our data primarily in terms of 8 bit bytes. But any file on your computer is just a stream of bits and could be processed in 3 bit chunks rather than 8 bit chunks. So, I thought, that means every file on my hard disk is potentially a piece of music.
I was up late playing with the Perl pack and unpack functions and eventually cranked out a simple byte to note converter that will take any arbitrary file as input and produces MIDI note data as output. After re-attaching a somewhat disused Yamaha keyboard to my Linux box, I picked a file to test the program with. I started small with a 1478 byte plain text file that contained a Backus Naur diagram of the Ring Tone Text Transfer Language. The result, while a bit odd, could be described as music of sorts. With seeming success at hand, I looked for more interesting data.
Next, I took a 24Kb JPEG photo of Nimon, one of our Geckos, and converted it. The resulting music had a Danny Elfman-like urgency to it and was a bit of an improvement over the RTTTL composition. However, the MIDI file was 500Kb and creating it consumed nearly all available memory on my box. It was at this point that I realized the MIDI::Simple module that I’d grabbed from CPAN wasn’t really designed for stream use or for large volumes of data. For some reason it wants to hold the entire collection of notes in memory before writing the output.
More interesting though, was that the real Nimon seemed to take an interest in the music created from her image. She came out from under the hollow log she usually sleeps under and stood on top of it holding her head up in the air as if listening. Who knows what a Gecko hears – maybe she was just feeling the vibrations from the sounds and thought an insect was around that needed eating.
No data is lost in the conversion and it should be trivial to convert the MIDI file back into the the original data. In fact, since the music uses only one timbre and is not polyphonic, it shouldn’t be too hard to convert from the music itself back to the original data. It’s not an efficient data transfer medium, however. Music usually plays at around 96 or so beats per minute, each beat is just 3 bits of the original data. So a 24Kb JPEG becomes an 11 hour musical work!
Despite the inefficiency of music as a data storage or transfer mechanism, tradition says that when a new way of encoding data is found, one has to encode the decss.c file. I present decss.mid, an illegal circumvention device in C Major, Opus 3.
Susan and I took some time off today and didn’t do any work. After a late breakfast we walked down to the park and fed some bread to the ducks and turtles. There’s quite an assortment of ducks this year including the usual white park ducks (well, I call ‘em park ducks but I think they’re really Pekin Ducks), Mallards, Muscovies, Northern Shoveler, American Widgeons, and Coots. It was warm enough that some of the turtles are begining to show themselves – mostly Red Eared Sliders. There were some assorted other things around like Egrets and Cormorants but they don’t eat bread so they just ignored us.
Afterwards we practiced our Tai Chi in the park – something I’ve never done before. We’re both able to get most of the way through the first sixteen positions though it gets a little tricky after the second set of brush-knees.
I’ve finished reading Jules Verne’s The Floating Island to Susan and now we’ve moved on to The Monk in the Garden by Robin Marantz Henig. It tells the story of Gregor Mendel and his experiments cross-breeding peas which allowed him to discover the principals of inheritance. So far the book is moderately interesting but the author feels if you can’t find enough facts to fill in the whole story, you should just make up something that sounds good so that the story flows along like a novel. So periodically, she will insert a paragraph or two of ridiculous speculation on what Mendel might have thought about or what he might have said to someone. Usually the made-up parts are about as historically believable as the dialog on the Hercules or Zena TV shows. Fortunately those portions of the book are infrequent and small enough they can be easily skipped.
Mozilla. 0.8.1 is out. My advice is to stick with 0.8. The new release is far less stable than 0.8 and is crashing several times a day (in fact it’s less stable the Netscape!). Also, it’s full of bugs that weren’t in 0.8. Yes, I’ve filed bugzilla reports on them, so I’m allowed to complain. :-) Hopefully they’ll get things back on track with the 0.9 release next month.
Meanwhile, robots.net is keeping me busy. Lots of Perl coding as well as lots of bugs fixes and changes to mod_virgule. One things that keeps amazing me about most of the web portal software like mod_virgule and slash and scoop is how primitive and slow they seem compared to the multi-user BBS software we used to have. It takes a fast Pentium II or III to do what your average BBS software could do back in the ’80s on a 20Mhz 80286. Mod_virgule seems a little better than the others (and has Raph’s cool trust metrics stuff – that’s something that does work better than what we had back in the good old days). I ran several of the old BBS packages for years and they were much more versatile in general. I’ll probably get all the features I need for robots.net hacked together out of mod_virgule and lots of Perl code but I think when I’m done I may just have to write an Apache module of my own that takes the best of modern web software and adds in the best features BBS software.
The DPRG held the regional for the Trinity College Fire-Fighting Robot Contest in Dallas today. I took a few photos and will try to post them tomorrow or Monday on robots.net along with a summary of the action.
Otherwise, I spent the day hacking on a Perl/DBI/PostgreSQL project. I’m looking forward to the release of PostgreSQL v7.1 (which will happen real soon now, hopefully). I keep hearing good things about how fast it is.
I also ran across the new 1040.com tax form for recently laid-off employees of dot-coms. I know a few people who’ll need it this year.
I managed to find some time to study the problem of sending ringtone data to my cell phone. As I mentioned in a previous news item, I’m sick of only being able to download silly melodies as ring tones and want to be able to create some ringtone datasets that more interesting ringing sounds. The first step towards that is to figure out how the whole thing works.
I’ve managed to code up a quick and dirty Perl program that creates an RTPL bitstring, converts it to text formatted hex data, and sends it to the phone in SMS format. At present it doesn’t really do anything useful besides providing a working example of the packet format and testing the sonic range of the phone. I’ve hard-coded a ringtone that emits sound over the entire range that the RTPL data can cover.
The next step would be to make some sort of algorithmic sound synthesizer that could generate RTPL data. If anyone wants to play with what I’ve got so far, I’ve put it up on our free software page. It should work with any Nokia phone that accepts ringtone data and perhaps other types of phones as well.
I was up late last night helping a client load-test a large web portal site they’re developing. The primary server is a Sun 250 with half a gig of RAM and dual CPUs. It runs Stronghold and the portal is a built on top of a bulky Java Portal architecture called Epicentric, which in turn sits on top of JRun & the Sun JVM. Like all Java-based stuff I’ve worked with it takes massive amounts of memory. Right now, the server can handle about 30 simultaneous users before things start bombing off. Running top, you can watch the available RAM drop in direct proportion to the number of users while the memory being used by Java increases. Once it hits the swap file, all the Java-based stuff starts failing and only static HTML pages continue to work (Stronghold, which is just a version of Apache you can pay a lot of money for, held up fine throughout the testing). At the moment I’m recommending they go to at least 1 Gig of RAM. It looks to me like the JVM is broken though, as it never releases any of the RAM it allocates. Hours after our tests it was still sucking up hundreds of meg of RAM, slowing the entire system to a crawl. Only way we’ve found to fix it is to kill Java and JRun and restart them. Yuck.
Everytime I read articles about how wonderful Java is I start thinking I should try switching to it for our own web apps. Everytime I work with a client who’s using it, I end up being thankful we still use mod_perl for our own stuff.
I’ve been working with a client using Epicentric to develop portal sites lately. I’ve worked on portals for other customers in the past and have lately started wondering what the most efficient way of developing these sorts of web applications would be. The Epicentric product is Java-based and relies on a fairly huge stack of software above the web server including a JDK, JDBC, a JSP server, and a Java servlet engine such as Jrun or Tomcat. Epicentric is a commercial portal app. Other (free) portal apps such as slash use the mod_perl approach – basically a Perl app combined with Perl DBI. Zope is Python-based (which I’m assuming would be slower unless there’s a Python equivalent to mod_perl?). And then there’s mod_virgule which is written in C but has no database interface (yet).
The question that I really haven’t found a satisfactory answer for is the speed/scalability issue. Which approach handles transactions faster and which scales to very large sites best? I’ve been unable to find any type of benchmarks or even anecdotal comparison of systems like these. I’m thinking about coding a simple benchmark program that simulates typical portal site operations in both mod_perl/DBI and Java/JDBC and comparing the speed and scalability using the same hardware, OS, database, and webserver. Has anyone done anything along these lines before? If so, I’d love to hear about it.
Someone on Advogato mentioned a new Perl site called Perl Monks. They have a much more elaborate trust/skill metric system than Advogato. I’m an Initiate (everyone starts out at this level and gains points through peer recognition over time). There are ten levels with amusing titles like acolyte, friar, pontiff, and eventually saint.
I got several replies from other old fidonet folks after my last news item, so there do appear to be others out there who remember the good ol’ days.
I ran across an interesting news story on Yahoo. Seems some French scientists have successfully used gene therapy to restore normal functioning of the immune system in two boys suffering from SCID (the disorder forces them to live in a sealed environment because they have no resistance to infection). The doctors made the gene modification by extracting bone marrow, inserting the missing genes, and then replacing the bone marrow in the body. Pretty cool.