how to vim remotely

Lately I've been developing code that needs to be tested on a remote server. I played with a few different scripts to scp changes to the server and decided I needed something stronger. I went looking for a plugin for VIM and found out remote file editing is part of the base vim function.

You can specify a remote file path via scp://user@server/path/to/file or scp://user@server//fully/qualified/path/to/file .

Saving the file with copy over the changes. Any local editing done on the file is done in a temporary file that is cleaned up when the editor is closed.

Updated interactive perl script

This is still just a quick script to test out perl concepts before trying to write them into a program. It isn't fancy but it is functional.

Look for more updates as I build this out a bit more:

#!/usr/bin/env perl

use Term::ReadLine;
use strict;
use warnings;

my $prompt = "> ";

my $term = new Term::ReadLine("iPerl -- interactive perl");

while (defined ($_ = $term->readline($prompt))) {
chomp;

next if (/^\s$/);
last if (/^(?:q|quit|exit|logout)$/);

my $output = eval $_ or print $!;

print "\nOUT: $output\n" if $output;
}

print "\n";

how to do ipython in perl...

I've been writing a lot of python code lately and I really enjoy having that instant trial and error you can get by using an interactive code shell. (IPython and a half dozen other tools allow this).

I had to switch to perl on a project and went looking for a similar tool. I wasn't able to find much out there but I did stumble on a quick solution.

perl -ne 'eval $_ ; print ">> "'

This will loop over all input from standard in and attempt to evaluate it. The only downside is you won't be able to write anything that takes multiple lines (for, while, try, or functions). But it is a lot easier than writing perl oneliners over and over again to test out theories.

to fix ubuntu speedstepping

For some reason my laptop decided to start scaling the processor back to the slowest possible frequency even when I was on AC power and running cpu intensive workloads.

I scanned for cpufreq modules in the kernel using

$lsmod | grep cpufreq

And I found nothing. I attempted to insert speedstep-centrino or acpi-cpufreq as a kernel module and found there were no modules to be loaded.

[~]$ sudo modprobe speedstep-centrino
FATAL: Module speedstep_centrino not found.

[~]$ sudo modprobe acpi-cpufreq
FATAL: Module acpi_cpufreq not found.

At this point I started looking at bug reports and user forums and I found the following:
* speedstep-centrino appears to be deprecated in favor of acpi-cpufreq
* acpi-cpufreq is actually compiled as part of the 2.6.31 ubuntu kernel so there is no module to load
* Ubuntu 10.x may revert to using acpi-cpufreq as a module but thats not confirmed
* cpufreqd and powernowd are userspace speed stepping daemons
* Ubuntu prefers powernowd but my system had cpufreqd installed
* hal (hardware abstraction layer) also has a speed step controller that no one talks about.

The last point is the one that tripped me up. I think the behavior I was seeing was hal getting confused when I would suspend the laptop, change from running on battery to AC, and then restart the laptop. The hald-addon-cpufreq daemon was doing speed stepping by setting min cpu = max cpu = target frequency. Which means switching the governors didn't do anything.

On the advice of a hal configuration bug report I found I removed the 10-cpufreq.fdi file I found in /usr/share/hal/fdi/policy/10osvendor/10-cpufreq.fdi and restarted the computer.

Removing the hal cpu controller, powernowd, cpudyn, and cpufreqd finally removed every last bit of automated control over my cpu speed stepping. I have cpufrequtils installed which gives me the ability to view and change cpu max, cpu min, and cpu governor manually. After the headache of trying to figure out why my cpu frequency randomly changed I think I'll stick with a system I can control.

flash followup

Apparently fixing flash on Karmic Ubuntu is easier and harder than I thought. I messed with various profile setting for a long while and still couldn't get GDK_NATIVE_WINDOWS to stick in all cases. It looks like gnome makes a habit of launching things outside of the context of the parent process.

I have everything working correctly now, but it took wrapping the firefox and prism executable with a one liner to set the environment variable

[~]$ cat /usr/bin/firefox
#!/bin/sh
GDK_NATIVE_WINDOWS=1 exec firefox-bin $@

That was enough to get it working again. Hopefully this saves someone some time.

how to fix flash in Ubuntu Karmic

This has been annoying me for a while now. I wasn't able to hit half of the buttons in flash games, youtube, or GrooveShark while running karmic. I figured an update in flash broke my system but it turns out the problem runs a bit deeper.

Gnome decided to enable client side rendering in their GTK windows. This allows for quicker and cleaner redraws when doing special effects. I happen to run fluxbox so I didn't notice anything in the switch. Eclipse users might be familiar with this since Eclipse hasn't handled the change yet. I stole most of this fix from their boards.

You can disable this new client side rendering using the environment variable GDK_NATIVE_WINDOWS=1.

My trouble was that it was impossible to get that variable to set anywhere in my config. I edited .profile (which is frowned on), .bash_profile (which is cheating since the variable won't make it into the window manager), /etc/environment (which sets it on a system level), and ~/.pam_environment (which sets it at a user level). None of these solutions would actually get the environment variable to stick.

Flash forward a frustrating half an hour of trial and error and I realized I started up the gnome-settings-daemon in my fluxbox startup script. I put a sleep after the gnome-settings-daemon and appended the GDK_NATIVE_WINDOWS assignment and everything started working. Turns out gnome-settings-daemon was hiding the environment variable changes. I have no idea how to reconfigure the setting daemon so I'm currently letting the hack stand (1 second delay and all).

Long and short of it: Add the line "export GDK_NATIVE_WINDOWS=1" to your startup files (any that I mentioned above) and keep in mind the gnome-settings-daemon might decide to squash them.

Hopefully that will spare you some troubles

how to improve graphics on a t60p running Jaunty (xorg 1.6 + radeaon)

Brian commented a few times on my last Jaunty post with some helpful advice. ATIRadeon Wiki posts the driver options for your xorg.conf file. Xorg 1.5 and up can run without the xorg.conf file by automatically guessing drivers and monitors, but it doesn't selected the tuned options all the time.

After my upgrade headaches I cleared the xorg file and started fresh, but I didn't think to add in the device options. I followed the wiki and performance is better, but not stellar. Compiz is still slow and multiple windows running transparency will bring the system to its knees. But its not all bad news. Fluxbox is finally acting the way it used to (desktop switches are quick, windows move without lag)

I still need to try out the radeon HD driver to see if that adds anything. For now I'll happily use fluxbox with Brian's tweaks and be content with it getting the job done.

PS: Brian, I wanted to visit your blog but your profile is blocked. Thanks again for the help