More than half of IT workers say they've fallen asleep at work, according to a new online survey.
Forty-nine percent of male techies say they've fallen asleep at work, while only 35 percent of women admitted doing so.
Hm. 49% of males, and 35% of females. Let M be the proportion of respondents who are male. It must be the case that (0.49*M + 0.35*(1.0-M)) = total proportion of respondents who say they've fallen asleep.
For what value of M can the total proportion who've fallen asleep be "more than half"?
Here I am, still trying to figure out how to simple I/O on a serial port under Windows.
I've just perused Microsoft's lengthy official article entitled "Serial Communications in Win32," and I remain no wiser. Oh, except for this gem:
"The Win32 API does not provide any mechanism for determining what ports exist on a system."
Yikes! I'd sort of assumed there would be such a mechanism, and I just didn't have a clue what it was. No mechanism???? [But see Update 2.]
I guess the article might be enlightening if I were already a Windows programming guru. To someone coming from another world, whether *nix or programming on the bare metal, it's a mixture of baby talk and arcane Windows-specific jargon. Kind of like a VMS manual.
(Oh, and those existing libraries that are supposed to enable Ruby to talk to Windows serial ports? I guess I could compile one of them. If I had a copy of VC++. Which costs... SEVEN HUNDRED BUCKS??? I don't think so. See why hackers like *nix? Shipping a *nix system without development tools is nigh-well unthinkable. Unless you're SCO, of course.)
When I first met UNIX, back in the 1970s, tty devices were treated like files. You'd open /dev/tty3 or whatever, use ioctl to set it the way you wanted it, and then use read and write to receive and send data. Simple. It worked.
MS-DOS also let you open a serial port as a file, using the magic name COM1: or similar. Unfortunately, you couldn't actually use the port this way, which is why every DOS application that did meaningful serial I/O talked directly to the hardware.
...Which is why, in turn, every general-purpose UART made since that time has had to emulate the register set of the NS8250. Which is why today's super-advanced UARTS are such a pain to use, being as how they're stuck with a crippled interface, multiple registers hidden at shared I/O addresses, and so forth.
(Microsoft was seriously Unclear On The Concept of device drivers. Back in the DOS days, I invented a new kind of mouse. Writing a device driver for a mouse ought to be easy, right? Just listen to the serial port, update internal data structures, and report movement to the operating system, no? No. The official Microsoft definition for a mouse driver called for the mouse driver, among its other duties, to draw the cursor on the screen. Which meant that a mouse driver had to know the details not only of the mouse and the port to which it connected, but also of every video card that ever had been or ever would be.)
The non-handling of serial ports was inherited by 16-bit Windows, and persisted at least up through Windows for Warehouses. I have a vague recollection that Win95 programs also commonly needed to talk to the hardware directly (though I may be conflating two projects here).
Anyway, it seems that the latest and greatest Windows still doesn't correctly handle serial-ports-as-files, and it's necessary to get intimate with the Windows API to use such ports meaningfully. The article seems to show the port being opened as a file, maybe with an extra flag set... and then the actual I/O descends into mystery. And even if I could make heads or tails of it, I still wouldn't know how to translate it into Ruby (especially as the various Win32 API modules for Ruby seem to be rather undocumented, but that's a topic for another rant).
Update: Oh, this just gets cuter and cuter! I decide to see what I can do with a serial port as a file, so I write a simple little-bitty Ruby script to open COM7, and loop reading and printing characters (the serial port being used only for input).
Then I run it. It wedges the interpreter, requiring application of the Task Manager to stop it.
OK. Is the port itself working? Launch TeraTerm, set it for COM7, set parameters, test function. Yup. Exit TeraTerm. Run program again.
Now the program buzzes around receiving EOFs on the serial port. When I send actual data from the other computer, it receives it. Hey! I can live with that!
Now I'm recalling what I saw with an earlier program that tried to read a serial port in Scheme. Sometimes it worked (EOF if the port was idle, character if there was one), and sometimes it didn't (interpreter wedged). Maybe the difference was whether or not some other program had previously used the port.
Unplugging and replugging the USB dongle that is COM7 returns it to wedgie mode.
Checking status before and after use of TeraTerm reveals that TeraTerm is leaving timeouts enabled. That makes sense, but didn't I try that already? Unplug, replug, set parameters (with timeouts enabled) with MODE command. Wedgie mode. Run TeraTerm. Mode COM7:/STATUS shows the same as before TeraTerm was run, and yet it works now.
So: programs that know how to use the serial port set some sticky property that's unknown to the MODE command. Isn't that just the cutest thing you ever heard of?
Update 2: Hmmm, the API may not know what COM ports exist, but it turns out the MODE command, sans parameters, does. This leaves only the problem of piping its output back into the application, and doing a bit of pattern searching. Oh, and setting the mysterious "make it start working" bit.
Update 3: Mayhap I've found the mysterious sticky attribute. According to an article I found at aspfree.com, there's a five-DWORD timeout array associated with each serial port, and it's persistent between applications. This seems to match what's going on. Now I just need to sort out how to make the necessary Win32API calls from Ruby, oh joy.
Update 4: Following much puzzlement, I've successfully retrieved and changed Windows serial port attributes with a Ruby script. Part of the trouble was lack of documentation, and part was a bonehead error in my test program.
I'll publish real live working code in a few days (got a busy weekend ahead, so probably no time to polish it now). Here's a snippet:
No, this isn't very good Ruby, what with the global variables and everything. When I have time, I'll wrap it in a class that extends File, and also have a POSIX version (require the module, and get whichever applies to your system), and have proper methods for converting comm parameter structures to and from hashes with symbolic keys. I'll probably also use the (undocumented) struct mechanism that seems to be part of the dl module, instead of cryptically-packed arrays.
[Missing links filled in from various places on the web, and in particular an unfortunately truncated comment by Derek Hans at Ruby Inside.]
So, yesterday evening, with everything apparently working, I clicked on the updater thingie on the Kubuntu laptop, and, after applying sundry updates, it helpfully offered to do a dist-upgrade from Extenuating Earwig to Flustered Flamingo.
It took overnight plus various responses to prompts. When all was said, done, and rebooted, it was working... except... my USB serial port was spontaneously disconnecting.
One quick Google got me to this page; removing brltty - and why would I want my serial ports to speak Braille, anyway? - indeed solved the problem.
The background pattern in my Gtk window still isn't showing up on that machine, but it's not like that's essential to the function of the program at hand.
El Reg is reporting that the LAPD is getting some sort of patrol-car-mounted airguns to fire GPS stickypods at getaway cars.
I had this idea back around 2003, only I figured on 12ga stickypods that could be fired from shotguns, or maybe 37mm or whatever caliber their tear gas grenade launchers or beanbag launchers are. The pod would have an impact-activated battery, and the serial number would be printed on the shell casing; in use, the cop would tag the miscreant's car, read the number off the fired casing, report it to HQ, and then knock off the high-speed chase while the tracking system (possibly using a cellphone network) did the following, and other cops could move to intercept.
And, once again, my wonderful idea has been read out of my very brain and developed by somebody else. Usually it's IBM that does that, but IBM only takes one year to do it.
We don't get a lot of those around here, especially in summer. I was thinking it wasn't summer anymore, but, according to the Bureau of Omphaloskepsis, the equinox isn't until the 23rd. Guess it's a Yom Kippur thunderstorm, not an official- changing- of- the- seasons thunderstorm.
Anyway, a few minutes before 8 this evening - maybe 50 minutes past sunset - it got noisy and flashy and wet out there.
The Ruby virtual-control-panel program being usefully working, I figured it was time to run it on the machine in the lab, so it'd be handily next to the actual hardware I'm working on.
The machine in the lab runs Windows. It has to; I run sundry commercial software on it, to talk to debug pods and the like.
First lesson: when installing Ruby on Windows, install to the default destination, C:\ruby, or you'll regret it later, when libraries can't be found.
Second lesson: When subsequently installing Ruby-GNOME2, force its installation directory to be C:\ruby, or it won't work at all.
Third lesson: installing ruby-serialport for win32 the obvious way doesn't work; it gives cryptic errors on the 'require.' Fortunately, the patch collection includes a gem for win32, in the form of a ZIP file containing sundry directories, in one of which lives the actual gem.
Fourth lesson: ruby-serialport 0.6.0-mswin32 doesn't in fact work, at least not with Ruby 1.8.6. Passing a port number gets ENXIO, and passing a port name gets "can't convert String into Integer." Looking at the source code, it looks like a String should just be used as the port name... and numeric arguments have to be in the range 1..8, which doesn't help me much, as my RS-485 USB dongle is COM10.
So, I guess its a choice among... er... reverting to a version of Ruby that matches up with serialport, or rounding up the resources to recompile the C file (no, I don't feel like buying a copy of VC++, thank you very much), or trying to bypass the whole serialport library and just using file I/O.
Or, of course, I could set up a Linux laptop on a tea table in the lab, and avoid the whole Windows mess for now. I was, however, kind of planning to deliver the program to the client, and the client mostly runs Windows (with one token Linux machine, though, for running exactly this sort of thing - it's even got an official-looking Debian license taped to it, drawn with genuine crayons).
Update: well, this is totally cute. I plug in the RS485 USB dongle, and Windows declares it to be COM10, as shown in the device manager. However! If I try to open COM10: as a file, I get ENOENT. Great going, Bill! (It's not user error. I can open COM7: just fine. Unfortunately, COM7 is an RS-232 dongle. COM10: just ain't fopen()able.)
Also, if I try to read from the file thus opened (using COM7 for now) within a thread, the entire Ruby interpreter gets wedged. Wasn't this the same problem (well, one of many) I had when I tried to use serial ports under Windows in Scheme?
On the brighter side, I have managed to get Gnome::Canvas to load an image and draw centered text across it, and then appear on the screen. Trickery is involved. I'll post the magic at some point.
Further update: I stumbled across the magic incantation for opening COM10 and above. Ready? Here we go...
$sp = File.open('\\\\.\\COM10',"rb+")
Isn't that just totally obvious? I mean, isn't it logical that the first 9 serial ports would be named COMx or COMx:, but beyond that they're called \\.\COMyz, and the name must not have a colon appended?
And it still doesn't actually work; the read wedges the whole interpreter, instead of just blocking the one thread. I'm thinking the solution may be to have the application speak Telnet to a little demon that provides a telnet-to-serial-port bridge. (I found one such program for ten bucks. I really want free-and-open-source, especially since it would be nice to be able to extend it to handle GPIB devices similarly.)
Or, I could just run the application on Linux, where it Just Works.
Yet more: there's another serial I/O package for Windows, called Win32Serial. I could wrap that in an abstraction layer that detects the platform, and uses serialport on *nix, and Win32Serial on Windows. Except that... there doesn't seem to be a compiled binary out there, and I don't have the freakin' compiler on Windows, and it's not just a matter of typing "apt-get install vc++" to install it. I don't really feel like rebuilding the whole Ruby system using MinGW or whatever.
Ah, well. I guess it's better just to move one little Linux laptop into the lab than to curse the Windows.
...Except that both laptops have kinda outdated installs. Getting the old (big, heavy) laptop updated from the Kubuntu "Extruded Eel" of several months ago goes quickly, as does installation of the required Ruby libraries. Meanwhile, however, I've got the newer (portable) laptop occupying the space in the lab, doing a truly massive dist-upgrade... after which I hope it'll still work (though I have a nagging suspicion I may have to compile X from source again, for that particular machine).
Final update: As it turns out, the dist-upgrade on the tiny laptop installed a version of the X server which plays nice with that machine. It does look, though, like I'll need to install a new kernel to get proper support for the USB serial bridge... it's recognized, and I can write to it, but for some reason input isn't getting through. Installing a new kernel may mean rebuilding stuff like the oddball WiFi drivers. Oh, well... the big old laptop runs the virtual control panel just fine, except that for some reason the background pattern isn't happening, so it has a plain gray background instead of the spiffy brushed-aluminum look. Guess I haven't mastered Gtk yet.
It seems an MIT student was arrested (and nearly ventilated and detonated) for having a "hoax bomb" in an airport.
Said hoax bomb consisted of a circuit board with LEDs on it, connected to a 9V battery.
Because we all know that terrorists openly carry bombs that have lights all over them. Don't they?
Isn't that, after all, how Israeli checkpoints operate - by watching for people with LEDs on them, or animated Aqua Teen Hunger Force signs, or other things that just shout "bomb"?
Makes ya wonder why our troops in Iraq have such trouble identifying enemies. Should be easy, shouldn't it? Anyone with LEDs: Evil Midnight Bomber What Bombs at Midnight. Anyone else: harmless civilian.
Oh, no! I just noticed a green LED on a speaker! It's a bomb! And there's an LED on my monitor! And two on the computer! And three on the UPS! And they all have wires connected to them! I'm surrounded by bombs! Nooooooooo!
Update: Boingboing has more details. Sheesh. MIT was there long before Logan Airport was, people; can't the airport goons get a clue about techies? (Of course not; if they could, they wouldn't be goons.) Back in my college days, I used to travel with a variety of homebuilt electronic gadgetry, wearable and otherwise, and the worst reaction I ever got was an idiot screener making me check my LED bow tie (which ended up on the wrong flight, so I didn't have it for the first day of the Wet Toast Computer Faire that year).
Not just playing... I've actually got a real live (small) application, using Gtk and serialport, running on my workstation and talking (over RS485 and a sloppy length of twisted pair) to the contraption on my lab bench, in the next room. I can use it to send commands and receive and decode status, and this has enabled me to find & fix some bugs in the target firmware before the client has the final hardware and test fixture ready. (I also had to fix a couple of bugs in the hardware, but that's normal.)
I'm highly impressed with Ruby, and it looks like it'll be my scripting language of choice for the next few years. Learning time aside, the actual coding for this little app was almost trivial... and that's starting from never having completed any sort of GUI application before. (The remains of a dozen half-written GUI apps, in a variety of languages from a variety of eras, lie strewn across my disk drives & backup tapes.)
I'm somewhat less impressed with the GUI toolkits. I'd already mentioned that Tk, while easy to use, rapidly comes up deficient, notably in the area of supporting PNG images. Gtk started out as the widget set for the GIMP, then got expanded beyond recognition as the widget set for Gnome, and it got rather, er, organic in the process - definitely an evolved thing rather than a designed one, and accordingly untidy. That leaves Fox/FXruby; it looks promising at first glance, but I just spent a while experimenting, and it gave me a headache - partly that the documentation isn't nicely structured, and partly that it doesn't have the nice object-oriented feel of Gtk. (Oh, there's also Qt, but that comes with license worries.)
So, it looks like I'll be focusing on learning the intricacies of Gtk, in its Ruby-GNOME2 manifestation, and probably wrapping my own metawidget layer around it (which works nicely for the things I've tried so far). Next up... writing text onto images; getting a handle on Happy TreeView Friends; and passing images to & from a real graphics library, such as GD.
Yes, Gtk's drawing and compositing capabilities are limited... and I want to define steam-gauge widgets, which require rotating the indicator image(s) before compositing with the background and bezel images. I think Fox can do that, but I don't really feel like learning Fox just now.
(What am I up to? Isn't it obvious? I'm using Ruby as sort of a poor man's LabView, and I just can't resist the temptation to include steampunkish features!)
Update: Grumblegrumblegrumble! Some essential documentation for Ruby-GNOME2 seems to be nonexistent. Like, the entire section on GnomeCanvas, for example. And the pesky Gdk::WindowAttr thing that's required to create a Gdk::Window, which appears to be a prerequisite for doing anything with Drawables. The mapping from the C API is not immediately obvious, so the documentation is kinda important.
Oh, well. There's some example code, and I can always dive into the source code for the library....
Awright, when I followed somebody's link this morning to Fred!'s video commentary (at Fred08, no direct link that I can find) on New Improved Hillarycare, my reaction was, more or less, "What the heck is Fred! smoking? He must have made that part up!"
But, no. According to this here AP story, Hillary is seriously proposing to make health insurance a mandatory prerequisite for employment.
Kinda the opposite of the current situation, eh? Now, the easiest way to get medical coverage is to get a job that includes benefits. Under Hillary's scheme... well....
You don't have a job, you don't have money, and you can't afford medical coverage. The obvious solution is to get a job and earn some money, yes? But, if the medical coverage has to come first, you're kind of up a creek, aren't you?
But, despair not! For surely the omnibenevolent Great White FatherMother in Washington will promptly come to rescue you from the hole she dug for you! Right?
Isn't this the sort of Connector Conspiracy nonsense that got big computer companies in big trouble, back in the days when dinosaurs roamed the datacenter?
The iPod is a fine product... but if it's going to be locked to proprietary software with this sort of "value-subtracted" feature, there's a considerable incentive to buy one of the (much cheaper) competing products that uses standard file formats and protocols.
On my way to the morning meeting, I heard a report on the radio of a traffic disruption involving someone crashing one stolen truck, and then stealing the truck of someone who stopped to help.
This afternoon brings helpful advice on the radio: don't leave your car running unattended to warm up. Somebody might steal it. (Apparently that's how the morning thief got the first truck.)
Now, color me modern, but I was kinda under the impression that cars made since, oh, maybe the 1970s don't need warming up. You just get in, start the engine, and drive. Works in my 1989 Jeep, and, for the most part, it worked in my 1973 Matador. (The Prius actually has a warm-up cycle, masked by use of electric propulsion for about the first minute.)
And we're not talking "warm up the car so the driver doesn't freeze in the bitter North Dakota winter" here. This was a mild late-summer morning in San Jose. I didn't note the actual early-morning temperature here in Sunnyvale this morning, but when I went out to fetch the paper in shorts & bare feet, it didn't seem the least bit cold.
It's all part of the plot, you see. Katherine Roubos goes to Uganda, converts all the Ugandans to gayness, they all die of AIDS, and Halliburton moves in, and, er...
Hmmm... but... Uganda's oil production is estimated at 0 bbl/day, according to the CIA World Factbook. You can't enslave dead people. People who die of AIDS tend to be scrawny, so it's no good rendering them for biofuel.
Must be there's really oil in Uganda, but Dick Cheney is keeping it a secret until he can kill off all the natives, at which time Condi will produce forged Italian documents purporting to prove that she's the rightful heir to the throne.
...getting persistent ads for V!@gra by e-mail. The spam filter has gotten pretty good at bouncing those.
But now Pfizer has started advertising the stuff on the radio. Obnoxiously.
Men! If the switch on your control panel has an "OFF" position, YOU may have an ILLNESS! You need DRUGS! The little blue pill will WELD your switch PERMANENTLY in the "ON" position where it belongs!
Disclaimer: the author has stock in Pfizer. You need those little blue pills. You know you do. Ask your broker if your bank account is healthy enough for investing. Always protect yourself and your heirs against blog-transmitted financial advice.
One of the side discussions at last night's rocket society meeting had to do with climate change - and the character of the computer models that are being used to make those scary predictions for the next century.
It is of course well known that computer climate models still have pesky known bugs, the most conspicuous manifesting themselves as butterfly effects.
One member claimed that there were rounding errors involved, and that rounding one way gives runaway warming, while rounding the other way gives - no, not money in my bank account - runaway cooling.
Anyway, I had a sudden inspiration. What if the butterfly effect is real?
If it is, the whole problem can be solved with a handwave. You just need a good enough model to calculate just where and when to wave your hand....
(On a non-silly note, I've had enough experience working with floating-point numbers to realize that loss of precision can lead to dramatic effects in iterative calculations, and that order of evaluation can matter in practice, despite what you learned in math class. Is there really any truth to the rumor that the climate-modeling crowd isn't minding the quality of the numbers inside their models?)
The smoke from that big fire up north has passed... and it's still autumn weather.
I started putting on weightsequestering carbon for winter about three weeks ago.
And, today, I've just seen the first tarantula of fall, at Rancho San Antonio (and I didn't have a camera with me).
Well, perhaps there'll be another hot weekend. I'd been thinking of revisiting Arroyo Seco this weekend or next... but the forecast for this weekend is something like 70 degrees in Hollister, which doesn't sound like jumping- in- the- river- for- an- extended- swim weather.
Slashdot links to a story about proposed European censorship... some eu.gov cretin wants to block web searches for dangerous subjects.
"I do intend to carry out a clear exploring exercise with the private
sector ... on how it is possible to use technology to prevent people
from using or searching dangerous words like bomb, kill, genocide or
terrorism," Frattini told Reuters.
To paraphrase somebody or other... there are no dangerous words, only dangerous people.
Of all the people who google for "genocide," how many do you think are looking for instructions on how to commit it? Or is Frattini trying to prevent people finding information about which they might become (rightly) outraged?
And someone searching for "bomb" or "terrorism" may well be looking for a current news story. One about which, again, he might become rightly outraged.
This sounds like the sort of idiot censorware that, years ago in the U.S., gained notoriety for blocking access to sites with information about breast cancer, classifying them as pornography. Heh, heh - you said breast!
Gimme sulphur to the measure two: Send the bullet where you want it to. Gimme charcoal to the measure three: Make the powder gonna keep you free. Gimme saltpeter, measure fifteen: Sweetest shooting that you've ever seen!