Due to a research project in which I'm currently engaged (and, trust me, you do not want to know the details), I find myself needing to wander into a public computer lab on our campus (where Windows rules the machines) and run a "virtual" Linux machine (because I'll be talking to a Linux server and, well, you really do not want to know the details). So I ended up using LinuxLive to create a USB flash drive from which I can run Linux Mint. Importantly, I can run it in a VM from Windows. Most USB installations of Linux distributions require that you boot from the USB, which in turn typically requires that you alter the order in which the PC polls devices looking for something to boot. That's not possible in my case; because the network police tend to lock down publicly accessible machines, I basically can't alter the boot sequence, and the boot sequence on the public machines does not include USB ports (let alone USB first). LinuxLive installs Oracle's VirtualBox. I just have to launch VirtualBox from Windows and then run my Mint machine in the VirtualBox VM ... in theory ...
After one full afternoon of futzing with this, I think I've got it working (knock on virtual wood), and I figured I'd write down a couple of the "gotchas" and their workarounds.
You install LinuxLive on a Windows machine and then supply it (besides the USB drive) either an .iso image or a bootable CD/DVD with your Linux distribution. It supports quite a few Linux distributions, including recent versions of Mint. The LinuxLive installer is very easy to use and the steps are documented quite well on the web site, so this should be a no-brainer. Except, um, the first time out it didn't work. I downloaded an .iso file for Mint 17 (the current version) and ran through the installation. Everything seemed to go fine, there were no error messages, and the installer told me it was done. When I tried to run Mint from the USB drive, though, I got an error message that the loader could not find vesamenu.c32. I located it manually (in the /syslinux folder), but it had a length of zero bytes, as did all but two files in that folder.
I was working in a campus computer lab, and by the time I tracked that problem down, I had to leave (and didn't have any media with me that could transport the .iso file). My next attempt was at home, using a CD with the .iso file for Mint 14. Small problem: the installer does not recognize Mint 14 as a known distribution (even though it is on the supported list) and consequently installs it as a generic Linux distribution. I cant' recall now if it did the same thing to me with Mint 17, but I think so. Among other things, this precluded me from setting up "persistence" (the ability to retain files on the USB stick between sessions), but I'm pretty sure I can work around that.
The installer told me it was done with no errors, and so it was time to test the USB stick. I had no trouble launching VirtualBox, where I found two virtual machines configured: "LinuxLive" (the production version of the Mint installation); and "Debug" (self-explanatory?). Starting the "LinuxLive" VM was an exercise in frustration. The good news was that it had no complaints about a missing vesamenu.c32. (Before trying to start it, I checked the driver and verified that this time the file had non-zero length.) The USB drive would flash, it would start to load something (couldn't really tell what from the largely blank display), and then ... nothing. It appeared to be frozen.
After assorted screwing around, I tried the "Debug" VM, where I at least got an error message: "This kernel requires an x86-64 CPU, but only detects an i686 CPU, unable to boot". Suffice it to say that my PC has an AMD 64-bit processor, and the Mint 14 distribution runs fine on it. After some searching, I discovered this was a consequence of the VM being set up for "other Linux" (i.e., fallout from the LinuxLive installer not recognize Mint 14). In the VirtualBox control program, I selected the VM and changed Settings > General > Basic > Version to "Ubuntu (64 bit)", which was as close as I could get to Mint (and, as it turns out, close enough). With that change, the Debug VM would boot.
The next problem was that the Mint asked for a user name and password. It turns out that, since I'm basically running a trial version, the user name is "mint" and the password is left empty. Once I figured that out, I could use the Debug VM ... but not the main (LinuxLive) VM.
Even after I switched the LinuxLive VM from "other Linux" to Ubuntu (64 bit), it would not boot fully. It would get to the point where the user name/password prompt occurs, then go dark, then reboot in an endless cycle, with the USB activity light flashing non-stop. So I compared the settings of the two VMs and discovered that, for unknown reasons, the Debug VM was configured to use 512 MB of base memory but the LinuxLive VM was configured for only 256 MB. I suspect the LinuxLive VM was being starved. At an rate, I changed Settings > System > Base Memory to 1024 MB for the LinuxLive VM and voila, it ran!
I'll screw around with adding persistence on another day.
Showing posts with label Windows. Show all posts
Showing posts with label Windows. Show all posts
Tuesday, July 8, 2014
Wednesday, June 20, 2012
MythTV versus Media Center
I'm still getting the hang of MythTV, but I think I have enough experience to make a reasonably informed comparison to Windows Media Center (WMC), which I used for years. A quick but important disclaimer is that, while I used the same hardware with both systems (other than an upgraded tuner that plays no role in the comparison), MythTV runs on the latest version of Mythbuntu whereas WMC ran on Windows Vista. I would expect the latest WMC, running on Windows 7, to be more stable and possibly have an improved feature set.
Regarding the last point, the BSoO was apparently a relative of the Blue Screen of Death (BSoD). This may be a Vista-specific "feature". Occasionally, when I opened WMC, I would encounter an utterly featureless black screen (maximized). Blindly clicking in the upper right corner would kill WMC, so the screen was actually alive and populated; it was just not painting. "Flipping" also worked (that's alt-tab task switching, not flipping the bird -- although I certainly tried the latter more than once). The truly annoying part, though, was that if you killed WMC during a BSoO and then restarted it, you were guaranteed to get another BSoO. This was also true if you killed it using the task manager. Once you saw a BSoO, your only remedy was to reboot the PC -- which could be rather inconvenient if you were trying to record live TV (particularly as Vista set no speed records for rebooting).
I think it was the BSoO that finally convinced me to brave MythTV. So far, so good with that change.
Where WMC has the edge
- Setup is much easier than with MythTV. I've documented some of my experiences setting up MythTV in other posts (click "MythTV" in the tag cloud, lower right, to find them). Familiarity with Linux (preferably Ubuntu), good skills using Google and nerves of steel are pretty much requirements (as might be the patience of Job). In contrast, with WMC you tell Windows whether you're using an antenna, cable or whatever, identify your signal provider, and you're off to the races.
- Data for the television guide seemed to download and install more rapidly (although this is a rather subject perception measure, and the guide source was different).
- The guide is free (or prepaid, if you prefer to look at it as bundled into the cost of the software). With MythTV, I pay a modest annual fee for guide data. (This is actually not an issue for me, since I was buying that data even when I used WMC, for reasons I'll articulate below.)
- The automatic download of guide data may be a bit more reliable than with MythTV (where I've already seen one instance in which the scheduled replenishment of guide data failed silently).
Where MythTV has the edge
- MythTV records shows in a reasonably standard format (MPEG-4, or something quite close to it). That means the recordings can be played by other software and can be transcoded. WMC, on the other hand, uses a rather nonstandard format (DVR-MS). Web searches suggest that it is possible to transcode them, but my first two tries ended in failure. Since VideoLAN's VLC player can play them, and since I have no interest in retaining the recordings once I've watched them, I gave up trying to transcode my accumulated DVR-MS files.
- MythTV can wake the PC from a G3 powered off state to record programs (assuming, of course, that the PC remains plugged into a live outlet). WMC, to the best of my knowledge, could only wake the PC from an S3 standby (sleep) state. I use the PC in question solely for recording and viewing television. Not having to leave it in sleep mode saves power, but perhaps more importantly it insulates me against power failures while I'm away on a trip. With WMC, if power happened to fail while I was away, the PC remained off once power was restored, and WMC could not wake it to record shows.
- I can schedule recordings by looking up the name of the show or by jumping to a date and time in the guide. WMC required me to open the guide (to the current date/time) and then scroll to the date and time of the show I wanted to recorded. I found it surpassingly strange that it had no option (or at least none I could find) to jump to a specific date/time.
- I can control how many days the guide contains. WMC downloaded however much data it wanted to download. In a few instances, when planning for a trip, I had to wait until the last minute to program recordings because dates late in the trip had not yet materialized in the guide. Although it never happened to me (that I recall), presumably on a long enough trip one would be barred from scheduling some recordings. (This "feature" is why I was already subscribed to the guide data that I ended up using in MythTV.)
- I have yet to see an analog to the Black Screen of Obfuscation (BSoO).
Regarding the last point, the BSoO was apparently a relative of the Blue Screen of Death (BSoD). This may be a Vista-specific "feature". Occasionally, when I opened WMC, I would encounter an utterly featureless black screen (maximized). Blindly clicking in the upper right corner would kill WMC, so the screen was actually alive and populated; it was just not painting. "Flipping" also worked (that's alt-tab task switching, not flipping the bird -- although I certainly tried the latter more than once). The truly annoying part, though, was that if you killed WMC during a BSoO and then restarted it, you were guaranteed to get another BSoO. This was also true if you killed it using the task manager. Once you saw a BSoO, your only remedy was to reboot the PC -- which could be rather inconvenient if you were trying to record live TV (particularly as Vista set no speed records for rebooting).
I think it was the BSoO that finally convinced me to brave MythTV. So far, so good with that change.
Saturday, May 19, 2012
Installing Mythbuntu with WinTV-DCR
A few years back, I bought a tower PC with Windows Vista Media Center (home version) and a tuner card built in. I've used it almost exclusively as a personal video recorder. For a variety of reasons, Vista has increasingly gotten on my nerves, so I finally bit the bullet and replaced it with MythTV. The process has taken much longer than I expected, partly due to dopiness on my part, partly due to sketchy instructions here and there (or presumptions that I know things I do not). Herein I chronicle some of the details in case they'll help anyone else. It will be a long post, as it was a long process.
I should note a few more things about my equipment before diving in. I am a Comcast cable customer. I run the incoming cable through a splitter, with one connection to the TV (flat-screen HD) through a set-top cable box and the other to the tuner card in the PC. The PC has an NVidia graphics card (the precise model is, I think, irrelevant) that connects to the TV via an HDMI cable.
The tuner in the PC can only capture analog channels (NTSC), and Comcast is moving more and more channels to digital. So part of the motivation of trying out MythTV was that I needed to install a new tuner in any case. After a little online shopping, I settled on a Hauppauge WinTV-DCR (model 2650), a dual-tuner CableCARD receiver that connects to the PC via USB. The 2650 is not explicitly recognized by MythTV, but according to multiple success stories by other people, you can falsely identify it as an HDHomeRun Prime and it will work fine with MythTV.
As I've mentioned more than once, I run Linux Mint on various PCs and laptops, so I initially thought about installing Mint on my PVR machine and then adding MythTV. A couple of things I read online about complications, coupled with the discouraging thought of downloading a potentially large number of dependent packages via my slow DSL line, caused me instead to download Mythbuntu 12.04 (at the office, where speeds are much greater) and burn an ISO image to a DVD. Mythbuntu is basically Ubuntu with things deemed inessential to a media server stripped out and MythTV added.
My initial thinking was to run Mythbuntu from the DVD, give it a test drive, then install it alongside Vista long enough to confirm that I liked it and to move my existing recordings over. Fortuitously, I took the precaution of copying almost all the recordings to an external hard drive before beginning the experiment. (The "almost" refers to one two-hour recording, approximately 5.3 GB, which could not be copied to the external drive. The issue was not lack of space; apparently the file was too large for the file system -- which might be FAT; I can't recall -- on the drive.)
Like other Ubuntu-based distributions, including Mint, you can boot from the CD or DVD, try out the system, and optionally install it. The test drive is useful to determine whether Mythbuntu correctly identifies and has drivers for your keyboard, mouse, display, network connections etc. In my case, this all worked fine, including installation of the NVidia proprietary drivers. For what it's worth, my keyboard and mouse are wireless, through a hub connect by USB. There was no problem with either of them.
I expected also to test MythTV itself, but as it turns out that cannot be done booting from the DVD. MythTV is a client-server system, so it comes with two parts, a front-end (client) and a back-end (server). You can test MythTV's front-end with a preexisting back-end, but if (like me) this is your first foray into MythTV, you will not have a back-end installed. No back-end, not test.
There was nothing for it but to install Mythbuntu. Mythbuntu initially gave me a screen with three choices, the first being to install alongside Vista. I chose that and took the default choice for disk partitioning. Shortly thereafter, Mythbuntu informed me that one of the partitions (it was not clear which; possibly the swap partition) was too small at the size it had selected itself and that I should back up and make it bigger. So I backed up and got what looked like the "how do you want me to install it" dialog again. Apparently I paid insufficient attention when I clicked the top choice, because this time the top choice was to wipe the old system and install just Mythbuntu. When I realized what it was doing (almost immediately) I ejected the DVD (the only way I could find to stop it), then reinserted the DVD and tried to restart the installation ... only to be told that the hard drive now had no system on it. To paraphrase Captain Keith Mallory, my "bystanding days" were over and I was "in it now up to [my] neck". A full install was on.
Thereafter, installation of Mythbuntu was quick and painless. There were 89 MB of updates awaiting me, which I deferred while I worked on the TV part. Physical connection of the WinTV was trivial (power cord, USB to the PC, attach the cable, insert the CableCARD). The installation screen lets you select an IR remote if you have one. I do, left over from Media Center, and selecting the standard Media Center remote worked ... for a while ... more about that below. The WinTV comes with its own remote, but I thought it would be easier to stick to the MCE remote (to which I'm used) rather than figure out how to get the WinTV remote to work.
For the video device, I selected the NVidia driver. There were a couple of drop down boxes to configure "TV-Out". I wasn't sure whether that was necessary, but I figured probably not; the prompt starts "If you would like to configure TV-Out". So I stuck with the default settings, which seems to have worked.
MythTV itself started, and suddenly the mouse was gone. My first thought was "how the heck do I navigate", but the keyboard arrow and tab keys worked fine. I later discovered this is a design feature, not a bug. When you are in a MythTV window, there is no mouse cursor. MythTV expects you to navigate via the remote. I wish I'd seen that somewhere before I launched into the installation, but no harm done. The remote worked fine to advance, retreat, select and cancel. At least it worked for a while (more to come).
In the video setup menu, I clicked the hi-def test button. It downloaded a 70+MB HD movie clip and played it successfully in the TV ... other than a lack of sound. The setup wizard theoretically allowed me to configure sound. I chose ALSA, but no joy. So I tried various other ALSA settings in the list (specifically those that mentioned NVidia), along with clicking the rescan button, and had no luck.
After a bit of searching, I exited MythTV, opened a terminal, and ran aplay -L, which showed me default:NVidia as a recognized sound device. That's what I'd hoped for, so I ran sound-test -Ddefault:NVidia -c 2 -t sine and heard tones in both of the TV's built-in speakers. (Sidebar: without the -t sine argument, you get "pink noise", which to me sounds like a bad connection.)
I then went back to the sound configuration screen in the front-end, and lo and behold the choice had changed, on its own, to ALSA:dmix:CARD=NVidia, DEV=0, and sound was working in MythTV. Maybe I forgot to try that one, or maybe my tests in the terminal somehow made the device more visible (?).
To configure the video source, I followed these instructions with minimal difficulty. I've had an account with Schedules Direct for a while, so my channel lineup was already configured. The one hiccup was that clicking Fetch channels from listing source repeatedly failed to do anything, until I realized that the CableCARD was not firmly seated in the receiver slot. (Paul slaps himself a few times.)
Pairing the device required a call to Comcast, in which I needed to give them three pieces of data: the card's serial number; a host ID, and a device (data) ID. The serial number was on the receipt I got from Comcast, but where to get the other two things? The back-end settings have a menu for Capture Card, in which I selected HDHomeRun Prime for each of the two tuners, and was given addresses for them and an IP address (on my home network, so a nonroutable address). This turns out not to be what Comcast wants. When you install the WinTV in Windows 7, the information is magically provided to you, but where would I find it in Mythbuntu? After a bit of searching, I indirectly stumbled on the answer. That IP address in the Capture Card screen was for a web server built into the WinTV. I opened that in a browser and it handed me the necessary information, including the serial number, on a silver platter. I called Comcast and in fairly short order had the card authorized (although they warned me it could take 45 minutes for the card to download all the channel information it needed).
Somewhere in the middle of this process I turned off the PC and went out to dinner. When I returned and booted the PC, the IR remote no longer worked! That's happened a second time as well. When I first observed this, I wasted considerable time searching for the source of the problem, playing with various remotes, and looking in the wrong places for where I could reconfigure it. (System > Control Center > Infrared is where I select the remote.) The lsusb command, run in a terminal, failed to show the remote being attached. As it turns out, unplugging the receiver's USB cable and then plugging it back in fixes the problem. I think I ran across some tweaks one can make in system files to eliminate the need to do that, and I will definitely research that tomorrow. I can't picture having to reseat the remote cable every time I wake the computer.
I have not yet tried to record anything, nor to import my Windows recordings, so there will probably be a follow-up post. Meanwhile, there are two pressing issues. One is fixing that bug with the IR remote. The other is to figure out why the first channel in my cable lineup (which happens to be ABC) is showing programming dubbed in Spanish (?!). All the other channels coming through the WinTV tuner are in English, and the one that is dubbed when viewed through the tuner is in English when viewed through the cable box.
I should note a few more things about my equipment before diving in. I am a Comcast cable customer. I run the incoming cable through a splitter, with one connection to the TV (flat-screen HD) through a set-top cable box and the other to the tuner card in the PC. The PC has an NVidia graphics card (the precise model is, I think, irrelevant) that connects to the TV via an HDMI cable.
The tuner in the PC can only capture analog channels (NTSC), and Comcast is moving more and more channels to digital. So part of the motivation of trying out MythTV was that I needed to install a new tuner in any case. After a little online shopping, I settled on a Hauppauge WinTV-DCR (model 2650), a dual-tuner CableCARD receiver that connects to the PC via USB. The 2650 is not explicitly recognized by MythTV, but according to multiple success stories by other people, you can falsely identify it as an HDHomeRun Prime and it will work fine with MythTV.
As I've mentioned more than once, I run Linux Mint on various PCs and laptops, so I initially thought about installing Mint on my PVR machine and then adding MythTV. A couple of things I read online about complications, coupled with the discouraging thought of downloading a potentially large number of dependent packages via my slow DSL line, caused me instead to download Mythbuntu 12.04 (at the office, where speeds are much greater) and burn an ISO image to a DVD. Mythbuntu is basically Ubuntu with things deemed inessential to a media server stripped out and MythTV added.
My initial thinking was to run Mythbuntu from the DVD, give it a test drive, then install it alongside Vista long enough to confirm that I liked it and to move my existing recordings over. Fortuitously, I took the precaution of copying almost all the recordings to an external hard drive before beginning the experiment. (The "almost" refers to one two-hour recording, approximately 5.3 GB, which could not be copied to the external drive. The issue was not lack of space; apparently the file was too large for the file system -- which might be FAT; I can't recall -- on the drive.)
Like other Ubuntu-based distributions, including Mint, you can boot from the CD or DVD, try out the system, and optionally install it. The test drive is useful to determine whether Mythbuntu correctly identifies and has drivers for your keyboard, mouse, display, network connections etc. In my case, this all worked fine, including installation of the NVidia proprietary drivers. For what it's worth, my keyboard and mouse are wireless, through a hub connect by USB. There was no problem with either of them.
I expected also to test MythTV itself, but as it turns out that cannot be done booting from the DVD. MythTV is a client-server system, so it comes with two parts, a front-end (client) and a back-end (server). You can test MythTV's front-end with a preexisting back-end, but if (like me) this is your first foray into MythTV, you will not have a back-end installed. No back-end, not test.
There was nothing for it but to install Mythbuntu. Mythbuntu initially gave me a screen with three choices, the first being to install alongside Vista. I chose that and took the default choice for disk partitioning. Shortly thereafter, Mythbuntu informed me that one of the partitions (it was not clear which; possibly the swap partition) was too small at the size it had selected itself and that I should back up and make it bigger. So I backed up and got what looked like the "how do you want me to install it" dialog again. Apparently I paid insufficient attention when I clicked the top choice, because this time the top choice was to wipe the old system and install just Mythbuntu. When I realized what it was doing (almost immediately) I ejected the DVD (the only way I could find to stop it), then reinserted the DVD and tried to restart the installation ... only to be told that the hard drive now had no system on it. To paraphrase Captain Keith Mallory, my "bystanding days" were over and I was "in it now up to [my] neck". A full install was on.
Thereafter, installation of Mythbuntu was quick and painless. There were 89 MB of updates awaiting me, which I deferred while I worked on the TV part. Physical connection of the WinTV was trivial (power cord, USB to the PC, attach the cable, insert the CableCARD). The installation screen lets you select an IR remote if you have one. I do, left over from Media Center, and selecting the standard Media Center remote worked ... for a while ... more about that below. The WinTV comes with its own remote, but I thought it would be easier to stick to the MCE remote (to which I'm used) rather than figure out how to get the WinTV remote to work.
For the video device, I selected the NVidia driver. There were a couple of drop down boxes to configure "TV-Out". I wasn't sure whether that was necessary, but I figured probably not; the prompt starts "If you would like to configure TV-Out". So I stuck with the default settings, which seems to have worked.
MythTV itself started, and suddenly the mouse was gone. My first thought was "how the heck do I navigate", but the keyboard arrow and tab keys worked fine. I later discovered this is a design feature, not a bug. When you are in a MythTV window, there is no mouse cursor. MythTV expects you to navigate via the remote. I wish I'd seen that somewhere before I launched into the installation, but no harm done. The remote worked fine to advance, retreat, select and cancel. At least it worked for a while (more to come).
In the video setup menu, I clicked the hi-def test button. It downloaded a 70+MB HD movie clip and played it successfully in the TV ... other than a lack of sound. The setup wizard theoretically allowed me to configure sound. I chose ALSA, but no joy. So I tried various other ALSA settings in the list (specifically those that mentioned NVidia), along with clicking the rescan button, and had no luck.
After a bit of searching, I exited MythTV, opened a terminal, and ran aplay -L, which showed me default:NVidia as a recognized sound device. That's what I'd hoped for, so I ran sound-test -Ddefault:NVidia -c 2 -t sine and heard tones in both of the TV's built-in speakers. (Sidebar: without the -t sine argument, you get "pink noise", which to me sounds like a bad connection.)
I then went back to the sound configuration screen in the front-end, and lo and behold the choice had changed, on its own, to ALSA:dmix:CARD=NVidia, DEV=0, and sound was working in MythTV. Maybe I forgot to try that one, or maybe my tests in the terminal somehow made the device more visible (?).
To configure the video source, I followed these instructions with minimal difficulty. I've had an account with Schedules Direct for a while, so my channel lineup was already configured. The one hiccup was that clicking Fetch channels from listing source repeatedly failed to do anything, until I realized that the CableCARD was not firmly seated in the receiver slot. (Paul slaps himself a few times.)
Pairing the device required a call to Comcast, in which I needed to give them three pieces of data: the card's serial number; a host ID, and a device (data) ID. The serial number was on the receipt I got from Comcast, but where to get the other two things? The back-end settings have a menu for Capture Card, in which I selected HDHomeRun Prime for each of the two tuners, and was given addresses for them and an IP address (on my home network, so a nonroutable address). This turns out not to be what Comcast wants. When you install the WinTV in Windows 7, the information is magically provided to you, but where would I find it in Mythbuntu? After a bit of searching, I indirectly stumbled on the answer. That IP address in the Capture Card screen was for a web server built into the WinTV. I opened that in a browser and it handed me the necessary information, including the serial number, on a silver platter. I called Comcast and in fairly short order had the card authorized (although they warned me it could take 45 minutes for the card to download all the channel information it needed).
Somewhere in the middle of this process I turned off the PC and went out to dinner. When I returned and booted the PC, the IR remote no longer worked! That's happened a second time as well. When I first observed this, I wasted considerable time searching for the source of the problem, playing with various remotes, and looking in the wrong places for where I could reconfigure it. (System > Control Center > Infrared is where I select the remote.) The lsusb command, run in a terminal, failed to show the remote being attached. As it turns out, unplugging the receiver's USB cable and then plugging it back in fixes the problem. I think I ran across some tweaks one can make in system files to eliminate the need to do that, and I will definitely research that tomorrow. I can't picture having to reseat the remote cable every time I wake the computer.
I have not yet tried to record anything, nor to import my Windows recordings, so there will probably be a follow-up post. Meanwhile, there are two pressing issues. One is fixing that bug with the IR remote. The other is to figure out why the first channel in my cable lineup (which happens to be ABC) is showing programming dubbed in Spanish (?!). All the other channels coming through the WinTV tuner are in English, and the one that is dubbed when viewed through the tuner is in English when viewed through the cable box.
Sunday, April 8, 2012
Resizing My Windows Partition
My laptop is dual boot -- Windows 7, Linux Mint 11 (Katya) -- and I ran out of space on the Windows partition. (Microsoft has never seen a disk drive it wasn't happy to fill up for you.) As it turns out, alleviating this was child's play (well, if your child is pretty advanced) once I figured out one little thing ... which I record here, since I'll not doubt forget it and then have to repeat the process.
I booted my laptop from the Katya CD. Like all Mint distributions, you can run Linux from the CD, which allows you to screw with the hard drive. Mint comes with GParted, the Gnome partition editor, which deserves every accolade that anyone has ever thrown at it. My hard drive started with a small boot partition, followed by the Windows partition (NTFS), and then one extended partition for Linux containing three logical partitions (home, swap and the main partition). All I had to do was:
Once that was done, I booted into Windows, which immediately ran chkdsk to square things away. I rebooted into Windows, and all looks good.
Actually, the first time I did this, GParted showed the correct (new) partition scheme, but when I got into Windows it showed the old partition size. Back to Mint and GParted, and sure enough, the old partition table was there. I'm not sure whether I screwed something up. The first time chkdsk ran, it rebooted when my back was turned, and so booted into Mint (the default) rather than Win 7. I don't know if that was the problem, or if somehow the modified partition table was not written the first time around. Anyway, it's all good now.
I booted my laptop from the Katya CD. Like all Mint distributions, you can run Linux from the CD, which allows you to screw with the hard drive. Mint comes with GParted, the Gnome partition editor, which deserves every accolade that anyone has ever thrown at it. My hard drive started with a small boot partition, followed by the Windows partition (NTFS), and then one extended partition for Linux containing three logical partitions (home, swap and the main partition). All I had to do was:
- Shrink the main partition (which had the most free disk space) to create some unallocated space.
- Move the main partition all the way to the right.
- Move the swap partition all the way to the right. The unallocated space was now at the beginning of the extended partition.
- Shrink the extended partition to give up the unallocated space (placing it between the NTFS partition and the extended partition.
- Expand the NTFS partition to soak up the free space.
- Apply all operations.
Once that was done, I booted into Windows, which immediately ran chkdsk to square things away. I rebooted into Windows, and all looks good.
Actually, the first time I did this, GParted showed the correct (new) partition scheme, but when I got into Windows it showed the old partition size. Back to Mint and GParted, and sure enough, the old partition table was there. I'm not sure whether I screwed something up. The first time chkdsk ran, it rebooted when my back was turned, and so booted into Mint (the default) rather than Win 7. I don't know if that was the problem, or if somehow the modified partition table was not written the first time around. Anyway, it's all good now.
AppFlower Tutorial Done
Following up on yesterday's post, I've completed the tutorial for AppFlower in which one builds a customer relationship management (CRM) system (or at least the framework for one). Along the way, I bumped into a few "gotchas" which I'll document here. I don't think we'll end up using AppFlower Studio, but not because of the few bugs I encountered (all of which seem to have work-arounds). AppFlower is based on Symfony, and I think our target applications would require a deeper understanding of Symfony than I'm willing to invest in (especially since our developers prefer to use Microsoft's ASP.net).
Anyway, herewith my notes on the AppFlower CRM tutorial (in somewhat random order).
Anyway, herewith my notes on the AppFlower CRM tutorial (in somewhat random order).
- There are minor discrepancies between the text (including images) and what you see in AppFlower Studio, possibly due to updates in Studio since the tutorial was written. They're harmless.
- The tutorial states that you can preview a form and use the preview to enter data into the database. I found the previews to be non-functional (neither the submit nor the reset button did anything).
- In fact, even when running the application, the reset buttons on forms did nothing (in particular, did not clear the form). I have no idea why.
- Some of the List views (in particular, listDeals) caused database errors when used, and prevented the dashboard from displaying. I'm not 100% certain, but I'm pretty sure this is tied to the presence of foreign keys in the models. The tutorial creates the foreign key relationship first (while building the model), then creates the form using the drag-and-drop interface to select fields. I found two work-arounds for the database errors. One is to create the model, including the foreign key fields, but not specify the relationships until after the list views are created. The other is to specify the relationship early (as in the tutorial), use drag-and-drop to create a list view containing everything but the foreign key fields, then add those fields manually in the widget inspector (right hand panel). I have no idea why the work-arounds worked, but they did. Curiously, edit views for models with foreign keys worked just fine with no tweaking.
- I discovered that if you return to an existing model containing foreign keys and delete a relation (not the entire field, just the relation), save the model, go elsewhere, then return to the model, the relation is back. The only cure for zombie relations that I found was to delete the entire field, then recreate the field without the relation.
- The tutorial has you create links to forms on the desktop (which work), and to specify "icon-plus" as the icon. No icon was displayed on the desktop for any of those links (nor is there one in the screenshot in the tutorial).
Saturday, April 7, 2012
AppFlower + VirtualBox + Win7: The Adventure Begins
As noted in my last post, I'm trying to get an AppFlower development environment running. My latest attempt is on my home PC (AMD-64 quad-core CPU), in a Windows 7 partition with lots of disk space. AppFlower provided a preconfigured virtual machine that should work inside Oracle's VirtualBox. The VM file is a 1 GB download that inflates to 4 GB when unzipped, but it represents a 20 GB virtual disk drive (and thus may grow).
Installation is carefully documented, with both step-by-step text instructions and a short video. Unfortunately, the video and the text do not always agree, and apparently sometimes both are wrong. If my tests of AppFlower convince me it fits our project needs, I'll be repeating this installation process, so I'd better document the issues here.
Time for some serious groping in the dark. AppFlower Studio includes (in the Tools menu) an easy way to open a console. The console, sadly, contained no error messages. Within the console, certain special commands can be run. Two of those are documented in the section labeled "AppFlower Studio Tasks - afs". I tried the first (afs fix-perms) thinking that perhaps Studio was unable to create the project directory due to munged disk permissions. It did not appear to help: the same nonspecific error message occurred when I tried to create the CRM project. So I tried the second (afs insert-diff-sql). It reported that it found no differences, but after running it project creation worked. If I have to go through this again, it's probably a good idea to run both commands. The first is at worst harmless, and it's possible that both were required to fix whatever was going wrong.
After creating the project, I was given a new port number. Pointing the browser at that port (on the same IP address that I using for the VM) opens the new project. Interestingly, the Studio BETA button in the new project has no option to create another project, nor to open other projects. The Studio BETA button in the "playground" (the instance I already had open) has both a create menu item and a recent projects menu item. (The new project did not appear under "recent projects" until I logged out and back in. I also changed the project name, in its settings dialog, before logging out of the playground and back in. I don't know if some tweak like that is necessary to make the playground take notice of the project.)
The next step is to complete the CRM tutorial and see if everything works.
Installation is carefully documented, with both step-by-step text instructions and a short video. Unfortunately, the video and the text do not always agree, and apparently sometimes both are wrong. If my tests of AppFlower convince me it fits our project needs, I'll be repeating this installation process, so I'd better document the issues here.
- The written instructions warn Windows users to enable IO APIC. The video instructions (perhaps not for Windows users?) omit this. It seems to be important, at least on Win 7.
- In the video, when playing with the VM's settings, the demonstrator explicitly disables the boot from USB and boot from CD options, so that boot from hard drive is the only choice. The written instructions are silent about this. I suspect it makes no difference, but better safe than sorry, so I followed the video.
- The video uses host-only networking of the VM, while the written instructions suggest bridged network first, NAT as a fall-back. Something I found in a response to a support question suggested that AppFlower Studio may go off on the Internet and download something when you create a new project. I suspect that cannot happen with host-only, although I'm not positive. On the other hand, I'm unable to connect my browser to the VM if it uses NAT. (I can connect with both host-only and bridged.) So bridged wins.
- Neither the video (at least not that I noticed) nor the text instructions says anything about turning off audio support in the VM settings. So I didn't (at first), and got warning messages while booting the VM. The warnings are harmless, but I think it best to turn off audio anyway.
- After installing and signing in, you're greeted by a splash screen. The documentation shows four quick link buttons, the first two of which can be used to create a new project or open an existing project. I see neither of those on my splash screen, just the last two buttons. Fortunately, equivalent functionality is available from the Studio BETA button in the top left after you get past the splash screen.
- The instructions to create a project show six steps. In fact, AppFlower Studio only lists four steps (steps 1, 3, 4 and 6 of the five shown, which are numbered 1-2-3-4 in the Studio beta). The disk location is automatically selected (a somewhat cryptically named directory is created on the VM), and the database is set up using a rather funky database name and automatically generated credentials. It will be interesting to see how hard it is, if we get to the point of deploying an application, to change the database settings.
Time for some serious groping in the dark. AppFlower Studio includes (in the Tools menu) an easy way to open a console. The console, sadly, contained no error messages. Within the console, certain special commands can be run. Two of those are documented in the section labeled "AppFlower Studio Tasks - afs". I tried the first (afs fix-perms) thinking that perhaps Studio was unable to create the project directory due to munged disk permissions. It did not appear to help: the same nonspecific error message occurred when I tried to create the CRM project. So I tried the second (afs insert-diff-sql). It reported that it found no differences, but after running it project creation worked. If I have to go through this again, it's probably a good idea to run both commands. The first is at worst harmless, and it's possible that both were required to fix whatever was going wrong.
After creating the project, I was given a new port number. Pointing the browser at that port (on the same IP address that I using for the VM) opens the new project. Interestingly, the Studio BETA button in the new project has no option to create another project, nor to open other projects. The Studio BETA button in the "playground" (the instance I already had open) has both a create menu item and a recent projects menu item. (The new project did not appear under "recent projects" until I logged out and back in. I also changed the project name, in its settings dialog, before logging out of the playground and back in. I don't know if some tweak like that is necessary to make the playground take notice of the project.)
The next step is to complete the CRM tutorial and see if everything works.
Wednesday, April 4, 2012
Adventures with WAMP and XAMPP
I'm experimenting with AppFlower -- a rapid (?) application development (RAD) tool based on PHP and the Symfony framework -- as a possible solution for a non-trivial web application project in my college. AppFlower/Symfony supports the MVC pattern for software development, which fits with our current practices. I'm cautiously optimistic that it will work for us, and if so I may report back here.
The plan was for me to install it on my laptop this afternoon and then go through a tutorial or two. I already have it running on my office PC (Linux Mint) in a VirtualBox virtual machine, but I prefer to use my laptop for development, since (a) it's faster than my somewhat antiquated office PC and (b) it's portable. Also, I'll be working with one or more of our IT people, who are all slaves to Windows. My laptop dual-boots Windows 7, so I figured I'd use the Win 7 side as my development environment.
As someone (Napoleon?) once said, the first casualty in every battle is the plan. It took me 4.5 hours just to install on my laptop. I don't need a virtual machine to run AppFlower under Windows, just a LAMP stack (give or take the "L"), and their website gives detailed instructions on how to install AppFlower to work with WampServer (a.k.a. WAMP), a very nice way to load an Apache-MySQL-PHP development stack on Windows. I already had WAMP installed and running correctly with other applications, so this would be easy, right?
Almost. All the configuration bits seemed to go smoothly until the last step, which is to run a Symfony configuration script via the PHP command line interface. There were a couple of hiccups here:
Well, no point in spending another four hours recounting where that first four hours went. Bottom line, nothing I did prevented the APPCRASH, so I finally gave up on WAMP, uninstalled it, and installed the Windows version of XAMPP. The instructions for installing AppFlower under WAMP also work, with minimal modification, for installing it under XAMPP. Some of the changes are quite minor (WAMP's control panel gives you a direct route to edit Apache's httpd.conf file, while in XAMPP I had to find it and open it manually in an editor). The only sticking point -- and this is strictly a consequence of my brain being fried by the time I got to it -- was that the virtual host set up in Apache for the AppFlower Studio app did not work. This was a copy/paste operation (copy the Apache directives from the instruction page, paste into httpd.conf. Well, with WAMP it's copy/paste. With XAMPP it's copy/paste/edit, because (duh!) the paths are different (C:\wamp\www becomes C:\xampp\htdocs, assuming you use the default installation paths for both). Interestingly (to me), AppFlower Studio will not open without the virtual host declaration. (I thought I could just give an explicit path to it in the URL. No such luck.) If I have to do this again (heaven forfend!), this page will hopefully remind me to fix the virtual host declaration.
So I seem to be up and running now, albeit too late to touch the tutorial today. XAMPP seems to be using a more recent version of PHP than WAMP was; perhaps that explains php.exe not crashing on the Symfony script, or perhaps it's something entirely different.
Oh, yes, note to self: the user name and password for both AppFlower Studio and the SeedControl demo that it comes with are both 'admin' ... which is not well documented, to put it mildly.
Update: Part of the AppFlower installation process is to add a VirtualHost directive to XAMPP's Apache configuration, so that the "host" name studio.local (which I mapped to 127.0.0.1 in the laptop's host file) points to the AppFlower web directory. This worked, but too well: it masked XAMPP's own document root, to the point that the built-in administration interface was hidden. The explanation is found in Apache's instructions for name-based virtual hosts. To avoid masking the original root, I need to add a second VirtualHost directive, using the original server name (in my case, localhost), point it to the original document root, and put it ahead of the one for AppFlower. (The AppFlower installation documents neglect to mention this.)
Update #2: I also need to insert a NameVirtualHost directive in httpd.conf, ahead of the first VirtualHost directive. Otherwise, the first VirtualHost (localhost for me) masks the second one (studio.local).
Update #3: Apparently, when installing on XAMPP and WAMP, AppFlower Studio needs to be told where to find the PHP executable. I fixed that, but I'm still getting error messages on most operations. They may be harmless, since the allegedly errant operation seems to have worked (possibly after manually refreshing the web page).
Update #4: I've given up on AppFlower with XAMPP/WAMP and may be having some success with VirtualBox (next post).
The plan was for me to install it on my laptop this afternoon and then go through a tutorial or two. I already have it running on my office PC (Linux Mint) in a VirtualBox virtual machine, but I prefer to use my laptop for development, since (a) it's faster than my somewhat antiquated office PC and (b) it's portable. Also, I'll be working with one or more of our IT people, who are all slaves to Windows. My laptop dual-boots Windows 7, so I figured I'd use the Win 7 side as my development environment.
As someone (Napoleon?) once said, the first casualty in every battle is the plan. It took me 4.5 hours just to install on my laptop. I don't need a virtual machine to run AppFlower under Windows, just a LAMP stack (give or take the "L"), and their website gives detailed instructions on how to install AppFlower to work with WampServer (a.k.a. WAMP), a very nice way to load an Apache-MySQL-PHP development stack on Windows. I already had WAMP installed and running correctly with other applications, so this would be easy, right?
Almost. All the configuration bits seemed to go smoothly until the last step, which is to run a Symfony configuration script via the PHP command line interface. There were a couple of hiccups here:
- the script turned out to be a bash script, which Windows had no idea how to handle (solution: find the php.exe file in the WAMP directory hierarchy -- it's not added to the system command path -- and run it explicitly against the setup script); and
- prior to running the script, I was told to tweak a setting in the php.ini file that might otherwise cause AppFlower some problems -- but there are actually two php.ini files, one in the Apache directory and one in the PHP directory (solution: once I realized this, I tweaked both the same way).
Well, no point in spending another four hours recounting where that first four hours went. Bottom line, nothing I did prevented the APPCRASH, so I finally gave up on WAMP, uninstalled it, and installed the Windows version of XAMPP. The instructions for installing AppFlower under WAMP also work, with minimal modification, for installing it under XAMPP. Some of the changes are quite minor (WAMP's control panel gives you a direct route to edit Apache's httpd.conf file, while in XAMPP I had to find it and open it manually in an editor). The only sticking point -- and this is strictly a consequence of my brain being fried by the time I got to it -- was that the virtual host set up in Apache for the AppFlower Studio app did not work. This was a copy/paste operation (copy the Apache directives from the instruction page, paste into httpd.conf. Well, with WAMP it's copy/paste. With XAMPP it's copy/paste/edit, because (duh!) the paths are different (C:\wamp\www becomes C:\xampp\htdocs, assuming you use the default installation paths for both). Interestingly (to me), AppFlower Studio will not open without the virtual host declaration. (I thought I could just give an explicit path to it in the URL. No such luck.) If I have to do this again (heaven forfend!), this page will hopefully remind me to fix the virtual host declaration.
So I seem to be up and running now, albeit too late to touch the tutorial today. XAMPP seems to be using a more recent version of PHP than WAMP was; perhaps that explains php.exe not crashing on the Symfony script, or perhaps it's something entirely different.
Oh, yes, note to self: the user name and password for both AppFlower Studio and the SeedControl demo that it comes with are both 'admin' ... which is not well documented, to put it mildly.
Update: Part of the AppFlower installation process is to add a VirtualHost directive to XAMPP's Apache configuration, so that the "host" name studio.local (which I mapped to 127.0.0.1 in the laptop's host file) points to the AppFlower web directory. This worked, but too well: it masked XAMPP's own document root, to the point that the built-in administration interface was hidden. The explanation is found in Apache's instructions for name-based virtual hosts. To avoid masking the original root, I need to add a second VirtualHost directive, using the original server name (in my case, localhost), point it to the original document root, and put it ahead of the one for AppFlower. (The AppFlower installation documents neglect to mention this.)
Update #2: I also need to insert a NameVirtualHost directive in httpd.conf, ahead of the first VirtualHost directive. Otherwise, the first VirtualHost (localhost for me) masks the second one (studio.local).
Update #3: Apparently, when installing on XAMPP and WAMP, AppFlower Studio needs to be told where to find the PHP executable. I fixed that, but I'm still getting error messages on most operations. They may be harmless, since the allegedly errant operation seems to have worked (possibly after manually refreshing the web page).
Update #4: I've given up on AppFlower with XAMPP/WAMP and may be having some success with VirtualBox (next post).
Thursday, December 29, 2011
Launching Windows Apps with Wine
Although I work almost 100% with Linux these days, I have a few Windows applications I find useful (including IrfanView for quick image edits and OCR -- much simpler, albeit less powerful, than GIMP) and PathSync for synchronizing local directories with my thumb drives. I also find PDF-XChange Viewer handy for adding annotations to PDF files. All these programs run fine under Wine, with one small "gotcha". When I install them (by downloading the Windows installer and then running "wine name-of-installer.exe"
in a terminal), shortcuts to them are added to the Wine submenu of the
GNOME menu ... but the shortcuts are often dysfunctional. They attempt
to launch the Windows .lnk
file added to the (virtual) Windows start menu, and typically I either
get a "file not found" pop-up or the launch simply fails silently.
The solution I have found is to manually edit the shortcuts. Suppose that I am logged in as user "paul" and I've just installed IrfanView. My first step is to track down the Windows path to the executable. Assuming defaults were used (generally a good thing when installing software under Wine), I open a terminal and drill down to /home/paul/.wine/drive-c/Program\ Files, where I find the IrfanView directory and, in that, the i_view32.exe executable.
The next step is to run
env WINEPREFIX="/home/paul/.wine" wine "C:\Program Files\IrfanView\i_view32.exe"
in a terminal and make sure that it launches correctly. Note that the path to the executable is written Windows-style (backslashes, no escaping things) in quotation marks. If the program launches properly, I close it, copy the entire line to the clipboard, find the launcher in the GNOME menu, right-click and choose "Edit properties", and replace the contents of the "Command:" field with the contents of the clipboard. I also confirm that launcher type is "Application" and not "Application in Terminal". With that done, I close the launcher edit panel and test it. Sometimes it seems to take a while before the menu detects and adopts the change I just made. I'm not sure, shy of logging out (overkill?), what the best way to impose the change immediately is. I've tried "killall gnome-panel" (possibly also overkill) with mixed success.
The solution I have found is to manually edit the shortcuts. Suppose that I am logged in as user "paul" and I've just installed IrfanView. My first step is to track down the Windows path to the executable. Assuming defaults were used (generally a good thing when installing software under Wine), I open a terminal and drill down to /home/paul/.wine/drive-c/Program\ Files, where I find the IrfanView directory and, in that, the i_view32.exe executable.
The next step is to run
env WINEPREFIX="/home/paul/.wine" wine "C:\Program Files\IrfanView\i_view32.exe"
in a terminal and make sure that it launches correctly. Note that the path to the executable is written Windows-style (backslashes, no escaping things) in quotation marks. If the program launches properly, I close it, copy the entire line to the clipboard, find the launcher in the GNOME menu, right-click and choose "Edit properties", and replace the contents of the "Command:" field with the contents of the clipboard. I also confirm that launcher type is "Application" and not "Application in Terminal". With that done, I close the launcher edit panel and test it. Sometimes it seems to take a while before the menu detects and adopts the change I just made. I'm not sure, shy of logging out (overkill?), what the best way to impose the change immediately is. I've tried "killall gnome-panel" (possibly also overkill) with mixed success.
Wednesday, March 9, 2011
Honey, I Shrank the Registry!
I have one rather superannuated PC running Windows XP, which I refuse to upgrade to Win 7 for various reasons (not least being that I suspect it would run at the speed of glacial drift, if at all). Lately, it's been complaining at boot that the system registry is too large, and that future requests for registry space will be denied (and the offending programs no doubt will be executed).
So I did a little searching and found a pair of free programs by a programmer in Germany named Lars Hederer: ERUNT and NTREGOPT. The former backs up and restores the registry (not a bad idea when you plan to perform surgery on it), while the latter compresses it. In my case, NTREGOPT reduced the registry size by 75% (!!), from around a quarter GB to something in the 70 MB range.
Hmm ... wonder if it could reduce my size (weight please; advancing age is already attacking my height) (and preferably not 75%).
So I did a little searching and found a pair of free programs by a programmer in Germany named Lars Hederer: ERUNT and NTREGOPT. The former backs up and restores the registry (not a bad idea when you plan to perform surgery on it), while the latter compresses it. In my case, NTREGOPT reduced the registry size by 75% (!!), from around a quarter GB to something in the 70 MB range.
Hmm ... wonder if it could reduce my size (weight please; advancing age is already attacking my height) (and preferably not 75%).
Sunday, March 6, 2011
Syntax Highlighting
I just burned about an hour of my life going back and retrofitting syntax highlighting to some of my old posts. The fault lies entirely with Bo Jensen, who first suggested it. Some of the code to be highlighted (including what triggered the suggestion) is in R, some in Java, a bit in Bash. (Thank goodness I got over APL decades ago; that would be a font nightmare.) Obviously, for blogging purposes, I need a highlighter that generates HTML, not just a syntax highlighting code editor. Given my rather modest output rate, an online highlighter would be just fine (no need to install it locally). Finally, and this turns out to disqualify several of the available R highlighters, I like having function names highlighted, not just keywords.
So I scrounged around the 'Net a bit and found two very useful sites:
One side note: This morning, by sheer coincidence, I received a couple of tweets from Hakan Kjellerstrand indicating that he was experimenting with a GPL version of the J programming language. Curious, I took a look at some code samples on the Jsoftware site and started having flashbacks to APL. While perusing the Wikipedia page for APL (linked above), I discovered that the flashback was not just random: Kenneth Iverson, the designer of APL, was also a designer of J.
I need to stare at some FORTRAN for a while to clear my head.
Update (9 March 2011): It's official -- I'm stupid. On my Windows box, I've been using Notepad++ for some time now (not so much for programming as for general editing of text files). As it turns out, Notepad++ does syntax highlighting for a variety of languages, including both R and Java, and can export to an HTML file.
Fine, but I do most of work on Linux Mint these days, and Notepad++ is a Windows-only program. It's based on Scintilla, though, as is SciTE, which I use for similar purposes on my Mint PC and laptop. (SciTE is also available for Windows, but I'm already using NP++ and, as we say here, if it ain't broke, don't fix it.) SciTE does Java highlighting out of the box, and with a small tweak, it does R syntax highlighting. It also exports to HTML. (The tweak: run SciTE via sudo, open the global options file, scroll down near the bottom and uncomment "import r", then save.)
So I'm set for highlighting with tools I'm already using.
Update (13 March 2011): I discovered a Linux command line utility named (shockingly) highlight. It converts code files in a variety of languages (including AMPL, which I needed today, but sadly not including R) to a variety of output formats (notably HTML, but also LaTeX). The utility is available from the Ubuntu universe repository, so you can load it via Synaptic without having to add a new source.
Of course, life can't be quite that simple. The executable is installed as /usr/bin/highlight. I already have a program of the same name at /usr/local/bin/highlight. I don't know where it came from or what it does, but it seems to expect input from stdin regardless of any command line switches. Since it's in the local bin directory, it loads ahead of the one I want (grrr). Not knowing whether it's part of a larger package, I'm reluctant to nuke it. So I've added alias highlight=/usr/bin/highlight to my .bashrc file, which gives me a safe (I think) workaround.
Update (10 July 2012): A reader tipped me off that Java code in one of my posts did not show up in Internet Explorer. When I looked at the blog in IE, I discovered one post where nothing appeared except the title and the footers! It turns out that in some cases I had inline CSS styles, but when I switched to highlight I was using a <style> tag to provide the style details. Although this worked fine in Firefox, Chrome and (for all I know) every other browser, it was enough to confuse IE. I couldn't find a way to generate inline styles with highlight, so I switched to Pygments, also available via Synaptic (and recommended by my namesake in the comments below). It provides both a command line program (which I use) and a Python library. The syntax I use looks like
pygmentize -f html -l java -o myfile.html -O noclasses,nobackground,cssstyles="background: #CCFFFF;" myfile.java
where the first option specifies HTML output, the second specifies Java input, the third (lower case "o") specifies the output file, the fourth (upper case "O") specifies options, and the last argument is the source code file to highlight. The noclasses option is the key: it forces inline CSS. The other two options suppress the usual background color in the <div> tag that surrounds the code and replace it with a color of my choosing.
So I scrounged around the 'Net a bit and found two very useful sites:
- Quick Highlighter, which handles most of my needs other than R; and
- Pretty R, which does a great job highlighting R code.
One side note: This morning, by sheer coincidence, I received a couple of tweets from Hakan Kjellerstrand indicating that he was experimenting with a GPL version of the J programming language. Curious, I took a look at some code samples on the Jsoftware site and started having flashbacks to APL. While perusing the Wikipedia page for APL (linked above), I discovered that the flashback was not just random: Kenneth Iverson, the designer of APL, was also a designer of J.
I need to stare at some FORTRAN for a while to clear my head.
Update (9 March 2011): It's official -- I'm stupid. On my Windows box, I've been using Notepad++ for some time now (not so much for programming as for general editing of text files). As it turns out, Notepad++ does syntax highlighting for a variety of languages, including both R and Java, and can export to an HTML file.
Fine, but I do most of work on Linux Mint these days, and Notepad++ is a Windows-only program. It's based on Scintilla, though, as is SciTE, which I use for similar purposes on my Mint PC and laptop. (SciTE is also available for Windows, but I'm already using NP++ and, as we say here, if it ain't broke, don't fix it.) SciTE does Java highlighting out of the box, and with a small tweak, it does R syntax highlighting. It also exports to HTML. (The tweak: run SciTE via sudo, open the global options file, scroll down near the bottom and uncomment "import r", then save.)
So I'm set for highlighting with tools I'm already using.
Update (13 March 2011): I discovered a Linux command line utility named (shockingly) highlight. It converts code files in a variety of languages (including AMPL, which I needed today, but sadly not including R) to a variety of output formats (notably HTML, but also LaTeX). The utility is available from the Ubuntu universe repository, so you can load it via Synaptic without having to add a new source.
Of course, life can't be quite that simple. The executable is installed as /usr/bin/highlight. I already have a program of the same name at /usr/local/bin/highlight. I don't know where it came from or what it does, but it seems to expect input from stdin regardless of any command line switches. Since it's in the local bin directory, it loads ahead of the one I want (grrr). Not knowing whether it's part of a larger package, I'm reluctant to nuke it. So I've added alias highlight=/usr/bin/highlight to my .bashrc file, which gives me a safe (I think) workaround.
Update (10 July 2012): A reader tipped me off that Java code in one of my posts did not show up in Internet Explorer. When I looked at the blog in IE, I discovered one post where nothing appeared except the title and the footers! It turns out that in some cases I had inline CSS styles, but when I switched to highlight I was using a <style> tag to provide the style details. Although this worked fine in Firefox, Chrome and (for all I know) every other browser, it was enough to confuse IE. I couldn't find a way to generate inline styles with highlight, so I switched to Pygments, also available via Synaptic (and recommended by my namesake in the comments below). It provides both a command line program (which I use) and a Python library. The syntax I use looks like
pygmentize -f html -l java -o myfile.html -O noclasses,nobackground,cssstyles="background: #CCFFFF;" myfile.java
where the first option specifies HTML output, the second specifies Java input, the third (lower case "o") specifies the output file, the fourth (upper case "O") specifies options, and the last argument is the source code file to highlight. The noclasses option is the key: it forces inline CSS. The other two options suppress the usual background color in the <div> tag that surrounds the code and replace it with a color of my choosing.
Subscribe to:
Posts (Atom)