I'm sure plenty of people out there have experienced looking for information on a website, only to be forced to go to Google and search for it via the "site:" option.
Well, I have a book on the Eclipse Rich Client Platform. I consulted the index to find information about Retargetable Actions. Unfortunately I didn't find anything.
So I jumped over to Google to search for information. The second result (or third if you count related results) was a link to O'Reilly's Safari. (Can you see where this is going?)
Those who are computer programmer types might notice that the time displayed comes out to 4,294,967,280 seconds, which is suspiciously close to 4,294,967,295 seconds. Even further, they might point out that Pidgin probably set the login time to -1, which when taken as an unsigned 32-bit number, comes out to 4,294,967,295 seconds.
From RFC 2616, in section 4.4.4, we see the following:
4.If the message uses the media type "multipart/byteranges", and the ransfer-length is not otherwise specified, then this self-elimiting media type defines the transfer-length. This media type UST NOT be used unless the sender knows that the recipient can arse it; the presence in a request of a Range header with ultiple byte-range specifiers from a 1.1 client implies that the lient can parse multipart/byteranges responses.
The best part of that badly mangled section has to be "the recipient can arse it."
In Round and Round, the submitter can't figure out why attempting to round 39.995 to two significant digits results in 39.99 and not 40.00.
If you're not a programmer, the answer is a little complicated. If you are a programmer, as the story submitter should be, and you can't immediately figure out what the answer is going to be - well, you need to study up on floating point.
In short, the answer is simply "computers use binary and 39.995 is decimal." The more complicated answer involves learning how floating-point works, but the bottom line is that it works just like decimal except with base 2.
Someone recently posted a very good comment on Slashdot detailing common PHP problems. Several of the replies give solutions to the various issues raised. However most of them involve editting php.ini to use safer options. (Why isn't php-recommended.ini the default config?)
Yes, there are ways around the problems listed. (Drupal, a PHP-based CMS which this site uses, provides quite a few helper-functions designed to make handling those errors much easier.)
However the point remains: when using PHP - be careful.
In a recent discussion about hosting Open Source projects, SourceForge inevitably came up. I recommended against it, siting stability concerns. I'd had severe issues with accessing a CVS repository I needed for a project. Where by "severe issues" I mean "worked once in the span of two weeks."
But that was quite a while ago. So I couldn't help but wonder if I was being unfair to SourceForge. Maybe they'd improved.
Well, I can't seem to access SourceForge-hosted websites right now.
Internet Explorer 7 is finally out. And... my site still doesn't work in it. Blarg.
I guess this means I'm finally going to have to get around to fixing Drupal's JavaScript to properly resize text areas instead of the current JavaScript which misplaces it due to the margins.
Plus several annoying rendering glitches remain (backgrounds randomly disappear while scrolling) leaving me with a page that just doesn't quite work.
