Here is one suggestion:

// countIfMissing: display the total count of observations, then
// any counts of missing observations for each variable in a list.
capture prog drop countIfMissing
program countIfMissing

version 11
syntax varlist

quietly count
local count=r(N)

// now make things align nicely
local sum=`count'
local tens=1
while `sum'/10>1 {
   local sum=`sum'/10
   local tens=`tens'+1
}
local width=`tens'+int(`tens'/3)
local varct: list sizeof varlist

di ""
di "Observations:"
di %`width'.0fc `count'
di ""
di "Missing:"
foreach varble in `varlist' {
   qui count if missing(`varble')
   local ct=r(N)
   local pct: di %4.2fc 100*`ct'/`count'
   if `pct'>0 {
      di %`width'.0fc `ct' " `varble' (`pct'%)"
   }
   else {
      local varct=`varct'-1
   }
}
if `varct'==0 {
   local offset=`width'+2
   di _column(`offset') "none of `varlist'"
}
di ""

end

For an example of usage, you can try this:

sysuse auto
local myvars "make price foreign"
countIfMissing `myvars'
countIfMissing m*       // (1)
countIfMissing _all     // (2)

As you can see in (1) and (2), the usual varlist conveniences apply here.

There was one line that I had to change, where Vim is ordered to clean up after itself. Every time you runDoLines() you produce a bunch of .tmp.do files in your %temp% directory, which Vim knows as $TEMP. Though this

au VimLeave * exe "!del -y " temp

should have deleted them, on my computer it did not. This one did:

au VimLeave * silent exe '!del /Q "'.$TEMP.'\*.tmp.do"'

Another thing I tinkered with was the way Vim handles these backup files that end in a tilde. You can disable them entirely, by adding

set nobackup nowritebackup

to _vimrc as explained here. You can also have Vim keep them somewhere you can delete them explicitly, in bulk, as explained here. Finally, you can use a combination of both: you save backup files while Vim is working, but then you make it delete them all when it starts next time. That is explained here. I went with it, so after I created a temp folder in $VIMRUNTIME, I added this to my _vimrc file:

" Keeps backups in $VIMRUNTIME\temp folder, cleans them up
silent execute '!mkdir "'.$VIMRUNTIME.'\temp"'
silent execute '!del /Q "'.$VIMRUNTIME.'\temp\*~"'
set backupdir=$VIMRUNTIME\\temp\\
set directory=$VIMRUNTIME\\temp\\

In the process of figuring this out, I also discovered that there's a quick way to clean up %temp% thoroughly, as shown here. Good to know. One of these days I might add that to _vimrc too. Now I'm on a roll.

I wrote a do-file, called work.do, that just uses a dataset, nothing more. That data set's name is handled by a local macro, defined in a separate do-file, called locals.do, which work.do includes. Then I wrote locals_program.do which does the same job via a program, which then work_program.do calls by name. Finally, I wrote a profiler.do file that called all four files a few times, and measured the time they all took doing their thing. According to profiler.do, an include is usually faster than a program. Below is the code:

// work.do starts here:
include locals.do
use "`my_file'"

// locals.do starts here
local file_path "C:/work/romanian papers circulation figures/data/"
local file_name "file_combined.dta"
local my_file   "`file_path'`file_name'"

// this is locals_program.do
capture prog drop defineMyLocals
program defineMyLocals, rclass

local file_path "C:/work/romanian papers circulation figures/data/"
local file_name "file_combined.dta"
local my_file   "`file_path'`file_name'"

local things "file_path file_name my_file"
foreach thing in `things' {
   return local `thing' ``thing''
}

end

// this is work_program.do
defineMyLocals
local my_file `r(my_file)'
use "`my_file'"

// and finally, this is profiler.do

set more off

cd "c:/work/programming/putterin/profiler"

// SECTION 1: OVERVIEW
/*
   1. What's going on:
   "program" vs. "include" profiler. this do-file defines
   two programs that will measure the performance difference
   in defining locals separately using two alternate ways
   (1) locals are defined in a do-file called with include
   (2) they are defined in a program called by name

   The exercise is to "use" a file. This file is called via
   a handle defined as a local macro. That definition can be
   either in a do-file included (1) or in a program called
   by name (2).

   2. Programs defined here and their dependencies:
   runProfile1
      defineMyLocals // defined in locals_program.do
   runProfile2
*/

// SECTION 2: GLOBALS

// SECTION 3: PROGRAM DEFINITIONS

// ### programs defined elsewhere and called via "run"
// ### locals_program.do defines the program named
// ### defineMyLocals, which returns a file handle
// ### as an r() local.
run locals_program.do

// ### work_program.do uses a file whose handle
// ### comes from calling defineMyLocals and
// ### retrieving an r() local.
capture prog drop runProfile1
program runProfile1

args counter

local time_start=tc("`c(current_date)'" "`c(current_time)'")
forvalues i=1/`counter' {
	run work_program.do
}
drop _all
local time_end=tc("`c(current_date)'" "`c(current_time)'")
di ""
di "Profile 1 (program), `counter' reps"
di "Time elapsed (ms): "`time_end'-`time_start'

end

// ### work.do includes locals.do, which
// ### defines a file handle as a local.
// ### work.do uses that file by calling
// ### that local.
capture prog drop runProfile2
program runProfile2

args counter

local time_start=tc("`c(current_date)'" "`c(current_time)'")
forvalues i=1/`counter' {
	run work.do
}
drop _all
local time_end=tc("`c(current_date)'" "`c(current_time)'")
di ""
di "Profile 2 (include), `counter' reps"
di "Time elapsed (ms): "`time_end'-`time_start'

end

// SECTION 4: PROGRAM CALLS

local cycles "100 200 500 1000 1500"
foreach cycle in `cycles' {
	forvalues i=1/2 {
   		runProfile`i' `cycle'
	}
}

And that's it. Put all five files into the same directory, make the profiler cd to it, change the path and name locals to your own data set, and see what you get on your machine. Below is my output:

Profile 1 (program), 100 reps
Time elapsed (ms): 2000

Profile 2 (include), 100 reps
Time elapsed (ms): 2000

Profile 1 (program), 200 reps
Time elapsed (ms): 4000

Profile 2 (include), 200 reps
Time elapsed (ms): 3000

Profile 1 (program), 500 reps
Time elapsed (ms): 9000

Profile 2 (include), 500 reps
Time elapsed (ms): 8000

Profile 1 (program), 1000 reps
Time elapsed (ms): 18000

Profile 2 (include), 1000 reps
Time elapsed (ms): 17000

Profile 1 (program), 1500 reps
Time elapsed (ms): 26000

Profile 2 (include), 1500 reps
Time elapsed (ms): 26000

Vim does not get confused by compound quotes and it comes with Stata syntax highlighting out of the box. Integrating it with Stata is not hard at all, either. There are some general directions by Nick Cox here, but on my Windows XP machine I just had to do two things.

First, I had to edit the PERSONAL/e/editors.ado file to make Vim replace Notepad++ entry in the Editors... sub-menu of the User menu:

program define editors
	version 10
	window menu append submenu "stUser" "Editors"
	window menu append item "Editors" "Vim" "winexec gvim.exe"
end

Next, I wrote a PERSONAL/v/vim.ado file like so:

program vim
	version 10
	syntax anything
	winexec gvim.exe `anything'
end

This is based on Nick Cox's recipe, slightly altered so you can launch Vim from the Stata command line to edit an existing do-file that say has spaces in it, as in vim "my dofile.do". There's a little more on this "syntax anything" solution in my previous Stata post.

One thing I did give up -- for now -- is the ability to launch a Stata instance from within Vim after I'm done editing a do-file, either for running the entire do-file or some select lines, the way I used to be able to do in Notepad++. There's got to be a way for that, though. If you know it, please drop me a line.

That said, I'd never knock Notepad++. It is still a fine text editor that has served me well. The people at Mather Economics, who adopted it a while back at my instigation, are sticking with it -- and I recommend it to anybody who does not insist on a modal editor.

capture prog drop myHello
program myHello

syntax namelist
local names `namelist'
di "Hello `names'"

end

myHello Eenie: Meenie

OK, so "illegal name" it is. Now let's see if "anything" might work better than "namelist":

capture prog drop myHello
program myHello

syntax anything
local names `anything'
di "Hello `names'"

end

myHello c:\my file path here\my file name here.txt

Success. This may look trivial, but everything is after the fact. We have a long-standing policy at the Eno River Analytics worldwide headquarters that we should write toy programs for sketching things out before we go ahead and actually break something.

Unfortunately, include does not work well with programs. You can invoke it inside a program but include itself cannot be compiled, so the do-file it refers to will have to be interpreted all over again every time you call that program: see help include for the original reference. This negates the speed advantage that you expect when you package your Stata work into programs as opposed to simple do-files. It does not negate all the other advantages -- such as better code portability and the possibility of unit testing -- but still, speed matters. My own solution is to define locals inside an r-class program. Then other programs that need some of these locals call that program, and recover only the locals they need. Below is one example, worked first with include and then with my proposed alternative:

// locals.do starts here
local file_path "c:/data/my_path/"
local file_name "file_name.dta"
local my_file    "`file_path'`file_name'"
// and ends here.

OK, now let's put these locals to work:

// work.do starts here:
include locals.do
use "`my_file'"

Alright. This is not bad and it does the job that your locals are neatly separated from the rest of the work. If you use do-files to split a big job into smaller pieces, this is all you need. If, on the other hand, you want to chop the job into pieces smaller still, and encapsulate those pieces into programs, then this is inadequate, as explained above.

The workaround might look like a bit more overhead, but then that's the usual cost of writing programs instead of plain do-files. Some of us, sometimes, find that overhead acceptable:

capture prog drop defineMyLocals
program defineMyLocals, rclass

local file_path "c:/data/my_path/"
local file_name "file_name.dta"
local my_file    "`file_path'`file_name'"

local things "file_path file_name my_file"
foreach thing in `things' {
   return local `thing' ``thing''
}

end

And now let's recover the local `my_file':

defineMyLocals
local my_file `r(my_file)'
use "`my_file'"

That's it. Your locals.do consists of the definition of the program defineMyLocals. The overhead is obvious. First, adding new locals inside this definition requires the extra step of adding their names to the things list, so that defineMyLocals can return them. Second, using defineMyLocals is also slightly more complicated than a simple include, because you need to recover the locals you need explicitly, via `r()'.

That said, now your locals are defined inside a program, and you can move them around faster. If you're like me and you favor programs over do-files and this isn't your solution, then I'd be curious to see your preferred alternative.

There was one small hiccup: one of the recent updates to rdesktop must have overwritten the /usr/share/rdesktop/keymaps/common file, because all of a sudden I could not use the Caps Lock key on the remote desktop. That's OK. I googled it as usual, and I found help here. Also as usual, those lively Ubuntu forums will send you all sorts of places before you hit something useful. You're happy when you find it, then the next moment you appreciate paid customer support. Then the moment after that you think OK, but it didn't take that long, and it didn't cost a dime. There's room for all of us, it seems. I wish Microsoft the best of luck. I wish Canonical the same.

Next up: fix the "Connect to Server..." item on the Places menu in Gnome. I can't SSH into the home server from there anymore. I can do so from a terminal window, and I can still auto-mount my home folder on the server via NFS, as documented earlier here and here. Auto-mounted NFS shares are best anyway, because that way my stuff on the server is available on the client automatically at start-up.

Take good notes, for one. While dabbling in an unrelated topic -- I was investigating how to enable wake-on-LAN for this machine -- I found a reference to a command I never knew existed: psearch. It's a port and I didn't have it installed, but whereis psearch led me to it quickly enough, and then it was just a matter of make install clean. Now, back to the portaudit problem: psearch libtool found the buggy port immediately: devel/libtool22.

I wasn't sure that this quick note was worth a post, so I left it in the drafts folder. But today's portaudit revealed multiple vulnerabilities in php5. Fixing that is in progress. Meanwhile I thought I'd post this thing after all, so I'll have a quick way to jog my memory next time I go looking for a well-hidden port.

One annoying thing is that I'm still unclear on when to use portupgrade -r, portupgrade -R, or portupgrade -rR. My default is the latter because I find it comforting that these recursive upgrades take care of all sorts of dependencies for me, both up and down stream. But man does it take a long time. That Pentium III is showing its age. It'd be good if I could safely cut some corners. So, dear readers, please comment away. I am curious.

I spend most of my work day connected to a Windows Server 2003 machine sitting in a colocation facility in Atlanta. I write and run Stata code on it, use the MS Office products, a bit of Gmail -- the usual stuff. As it turns out, the Ubuntu half of my computer has a much slower connection to this thing than its Win XP Pro sister does. It's so bad it's heart-breaking. I like Ubuntu, but I can't type very well with a two to three second lag. This should not have happened. Before I turned my main machine (a Dell Latitude D630) into a dual-boot system I had puttered around with a Dell Latitude D400 running Hardy LTS. I was pretty happy. I certainly don't remember the VPN connection on that computer being this slow.

Google didn't help much. There is some consensus that tsclient with RDPv5 is slower than mstsc.exe (the program behind the Remote Desktop Connection on Windows XP), but it doesn't sound like the difference is as painful as I'm feeling it. I have not found any working guidance to maybe fire up rdesktop without tsclient, which I was hoping might speed things up a bit, under the hypothesis that fewer apps in the chain are better than more. So I am not sure if the standard-issue Ubuntu solution -- tsclient+rdesktop -- has suffered some performance decrease between Hardy and Jaunty, or getting a remote desktop in a bigger full screen is going to be that much slower. I have no other ideas.

Has anybody seen this before? One thing that might still save this migration project is that the server in Atlanta is on its last leg, to be replaced soon by a far better system, running 64-bit Windows Server 2008. That should come with a Remote Desktop server with RDP version 7 according to Wikipedia. Maybe that will speed things up a bit on my end too -- if not right away, maybe another month or two into Karmic.

FreeBSD, for example, will sometimes turn up a damaged package or two in response to #portaudit. The procedure for that, according to the relevant chunk of the FreeBSD Handbook is that you only need #portsnap extract when you run #portsnap fetch for the first time. After that, you already have a ports tree on your system, and all you need is #portsnap update.

Had I remembered that, I wouldn't be sitting here writing this post while my ports tree is rebuilding itself for no good reason. On the same topic (of things to remember): according to the same FreeBSD Handbook, I should run #pkgdb -F once in a while, pretty much before every #portupgrade. An overview of what that does is here.