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.