When I was a kid (10 years old or so), I came across a program called LOVEDOS.
LOVEDOS gave every impression of being the normal DOS shell, except that the directories shown by "dir" clearly weren't your own, the files clearly weren't your own—And the computer was coming on to you, in various subtle and not-so-subtle ways. The only way to exit the program was to type "I love you" at c:>
I put it in my step-dad's autoexec.bat.
So on Rosetta Code, we use GeSHi for syntax highlighting. The relationship between Rosetta Code, GeSHi, a programming language and the code written in that language is fairly simple. (The exact order of events inside GeSHi might be slightly different; I haven't delved deeply into its core)
Rosetta Code (by way of a MediaWiki parser extension) gives GeSHi a few pointers about how it wants the code formatted, the language the code sample will be in, and, finally, the code sample itself.
GeSHi takes the code example, and loads the language file named after the language in question. Each language file defines a PHP associative array that contains(among a couple other things) simple rules for how GeSHi can apply formatting to the code in a way that will clarify it to the viewer. These rules include lists of known keywords of various classifications, symbols used for normal commenting conventions and optional regex matching rules for each, among other things.
It's a perfectly reasonable, fairly static approach that allows syntax highlighting to cover a broad variety of languages without knowing how to parse that language's actual syntax, and so avoiding having a syntax error break the whole process.
Unfortunately, it requires Rosetta Code to be able to tell GeSHi what language a code sample is written in. It also leads to odd scenarios where a supported language and an unsupported language are so closely related that examples written for the unsupported language can be comfortably highlighted using the the rules for the supported language.
And I have yet to learn of a good way to do syntax highlighting for Forth. (The Forth developers appear to pretty much keep to their own community, and don't seem to do much in the way of outreach, which makes finding a solution relatively difficult, but I digress...)
So what does this have to do with artificial intelligence? Well, in identifying a language without being told what it is, of course!
A few solutions have been discussed. One approach that has been attempted had something to do with Markov Chains. The code is in the GeSHi repos, and I haven't looked at it.
One solution I suggested was to run the code example through all the supported languages (Yes, I know, that's expensive. Not something to be done in real time.), and select the ruleset based on how many rules(X) were matched for a language and how much of the code sample was identified(Y). Using a simple heuristic of (a*X)/(b*Y), you can account for a number of matched rules while hopefully accounting for an overly-greedy regex rule.
How can we take this a step farther? How about formatting languages we don't know about?
Well, many, many languages have rules in common. Common keywords, common code block identifiers, common symbols for comments, common symbols for quotation, etc. This tends to result from their being derived or inspired in some way by another language. For the sake of avoiding pedantry, I'll just say that C, C++, Perl, Python, PHP, Pascal and Java all have a few common ancestors.
One way would be to note the best N language matches, take an intersection of their common rules, and apply that intersection as its own ruleset. This would certainly work for many of the variants of BASIC out there, as well as specialized variants of common languages like C and low-level ISAs.
The Wireless:
I have to think that when someone at ASUS submitted a design proposal for this device, what they had in mind was what a wireless router would do if it were designed by Tim Taylor, and then trimmed it back so that it'd be legal.
To start with, here are a couple paragraphs taken from its quicksetup guide:
"This device and its antenna(s) must not be co-located or operating in conjunction with any other antenna or transmitter."
"To maintain compliance with FCC's RF exposure guidelines, this equipment should be installed and operated with minimum distance 20cm between the radiator and your body. Use on[ly] the supplied antenna."
Don't panic, the wifi transceiver in your laptop isn't going to sterilize you.
I stopped by #hamradio on Freenode to discuss it, and wound up looking up the FCC ID on the FCC's website.[1] I pulled a copy of the correspondance regarding the RF exposure, to figure out what's going on.
First, according to that correspondance, the maximum safe exposure limit for RF in the 2.4GHz range for uncontrolled exposure (i.e. consumer setup) is 1mW/cm^2. Taking the inverse square law backward 20cm, that tells me that the antenna is radiating at 4000mW, or 4W.
Taking this back to #hamradio, it was explained to me that 4W is the maximum legal[2] ERP[3] for a one-to-many link[4] on the 2.4GHz unlicensed band. The prohibition on using a different antenna is so that the consumer doesn't replace it with an antenna that has a higher gain than the one that came with the router.
The RF exposure documentation in the correspondance between the engineers in Taiwan and the FCC also contains the design and specs of the antenna, which indicate the antenna is omnidirectional and has a gain of 1.9dBm. If the consumer uses an antenna with a gain higher than that, they risk going over that 4W ERP limit, which in turn brings us back to that 20cm safe distance warning.
4W is more than enough, though; My laptop used to be able to pick up seven or so wireless networks from the neighborhood sitting right here in the house. Now I can only see me, most of the time. I imagine it's possible to see me from Ottawa county.
[1] If you're curious, the FCC ID is MSQWL520GUGC.
[2] Possibly only so for unlicensed user; A licensed ham gets more privileges, but there are additional
strings attached. Unlicensed equipment and configurations are targeted for the least-common-denominator.[3] Effective Radiating Power; Essentially how much energy you'll see coming out of an antenna.
[4] This is something of an odd requirement that I may not understand properly. The assumption, apparently, is that if you're going to have a higher effective power output, you're only going to use it for point-to-point links. There's also a rule saying you should only put out as much power as needed for the application, but that would seem to leave things a little loose, still.
The Wired
The WL-520GU has four 10/100 LAN ports built in, as well as a WAN port presumably for attaching to your DSL or cable modem. Fine for access from a wired device to a wireless, or from a wired device to the Internet by way of today's broadband, but it's not going to grant impressive degrees of performance going from one wired device to another. If you have need of high-speed data transfer from two wired devices, it's probably best to chain the WL-520GU with a gigabit switch, and accept that you'll be stuck sharing a 100Mb pipe between wired-to-Internet and wired-to-wireless connections.
The Firmware
This is the part that Tim Taylor overlooked. The firmware has a great array of features, even going so far as to provide an AJAX-augmented web interface that gives you a live overview of your network in your browser, complete with problem analysis and diagnosis.
But they missed some of the more basic points of having functional software. So far, I've hit three nasty bugs.
The first bug I encountered was related to the first configuration option I changed: I turned off the wireless radio until I had everything configured the way I wanted it. I got everything configured, and then I turned the radio back on. When I turned the radio back on, the firmware lost all of the configuration settings I'd put in, defaulting to a completely open (no WEP, no WPA, no nuthin') 802.11bg network with an SSID of "default" and a broadcast power of 4W[1]. Not fun.
The second bug (well, there are two here) I encountered was in the configuration of the router's IP address. At first, I accidentally told it to change the IP address outside of the network's IP range and netmask. It kindly warned me that I was being stupid, so I clicked Cancel. And it kindly went ahead and applied the changes anyway. The second half of the bug was when I got in for another go, and discovered that it wasn't possible to set them at the same time; The interface lost the configuration as soon as you switched to the other property page; You had to click Apply in order to save the changes. At which point you were hosed. It's this second half of the bug that may well have caused me to discover the first half.
The third bug was the most nefarious, and cost me several hours and a second call to Comcast tech support. When you click Apply? It applies changes to its configurations, and implies it's going to reboot, shows a pretty "progress meter", and so on. When you click Reboot? Well, it tells you it's going to reboot, has the browser show a pretty "progress meter" of the percentage of the bootup, and then lets you go on and do your thing. Or try to; The router never really reboots, and you can see that by watching the lights on its front. That, in turn, helped confuse Comcast's modem[3], which in turn made things difficult for me.
[1] I add this for a bit of perspective. There's no configuration option for controlling the radio power output, but for about twenty minutes[2], I had a completely open wireless network visible to much of the suburb.
[2] It took me that long to make the connection between "I'm not able to attach to my network" and "wait...default...that's ME?!" I assumed I'd screwed up a setting on my laptop, or that it was looking for the old router's MAC address, or something along those lines.
[3] Whose firmware is pretty shoddy in itself. There's a reason they tell you to power off the router and modem, bring up the modem, and then bring up the router. I used to think Comcast was logging MAC addresses and hostnames, but that was apparently based on a coincidence of "try this theory and see if it works" and "it works!" combined with poor process control. At this point, I think the modem simply drops any DHCP packets once there's a lease in place, until the lease expires. But I'm definitely not interested in poking it to test this.
The Conclusion
I'm not going to make any conclusions. I've drawn up all my observations and the like above. Look them over and figure it out if it works for you. For my purposes, it Works For Now. But I'm back in the position where I don't even want to breath on the configuration for fear of spending horrendous amounts of time getting the connection to the Internet working again.
In my opinion, the WL-330gE was a much more solid product. I used one as my home router for over a year and a half, and liked it enough to buy a second. I won't be buying a second WL-520gE. If this guy dies, I'll probably buy a wired-only router, and use one of the WL-330gEs as an access point to the wired network.
Caveat Emptor.
But what about (custom firmware)
I don't feel like messing with it. Might solve problems, but I really don't feel like messing with it. There's even a firmware community built around the WL-500 series. But I really don't feel like messing with it.
So someone on IRC by the name of "lisard" was having difficulty with their internet connection, and their IRC client was using "lisard2" and "lisard3" as alternate names when the IRC server hadn't yet decided that the original lisard was no longer connected.
And this burst out of my head and onto the channel...
Three little lisards sitting in a channel
All in a row, and none wearing flannel.
One in the morning
Two to-day
Three in the evening
Four on the way
