Ranting a bit… I am pretty new to actually using GitHub but so far I am 0-2 on pull requests. The first I was trying to improve perl-support.vim but apparently the GitHub history was broken due to the original repo being re-created so I ended up sending my pull request to some random (nice) person’s fork. Last night I spent an hour or two fixing a couple of open issues on taskpaper.vim only to have them closed today without comment. I know I’m not supposed to take it personally or anything but to me it feels disrespectful and unappreciative to not even comment. It takes all of 10 seconds to clarify that it was being rejected and why. Instead I feel like I wasted a bit of my time and had to spend more time trying to figure out what the result actually was. I guess going forward I’ll just be sure to open a dialog before investing any of my time writing code which probably means I’ll just lose the spontaneous interest to even do anything.

After uninstalling the old Xcode and installing the new Command Line Tools for Xcode I ran into an error with Homebrew:

$ brew upgrade tmux
==> Upgrading tmux
Error: No such file or directory - /Users/nnutter/Error: 
$ brew upgrade  --debug tmux
==> Upgrading tmux
Error: No such file or directory - /Users/nnutter/Error: 
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/pathname.rb:434:in `lstat'
...

There is already a GitHub issue up for it with a proposed fix:

sudo xcode-select -switch /usr/bin

+1 for open source, open development, and GitHub.

I tried to uninstall Xcode tonight so I could grab the new self-contained .app (and command line tools) but was getting a message that “Xcode appears to be running” despite it not:

iMac:/Developer
$ sudo ./Library/uninstall-devtools --mode=all
ERROR: Xcode appears to be running.  You must first quit the following programs before the uninstaller can proceed:
...

It turns out the script parses $0 to determine the path to look for running programs:

 96 my $uninstaller_script = $0;
 97 my ($uninstaller_dir,$uninstaller_script_basename) = parse_name($uninstaller_script);
...
101 my ($developer_dir,$developer_dir_basename) = parse_name($uninstaller_dir);

Simply using the absolute path resolved the issue:

$ sudo /Developer/Library/uninstall-devtools --mode=all
Start time: Thu Feb 16 22:32:03 CST 2012
...

I spent a bit of time over the past few days playing with Class::C3, MRO::Compat, and mro. Class::C3 guarantees that subclasses will always appear before their parent classes in the method resolution order (MRO). (See “How does C3 work?“). If you want to do multiple inheritance then C3 seems to be the way to do it “right”. I am interested in C3 because I am exploring Mixins and whether they would be of use in UR.

If you are using Perl older than 5.9.5 then you will need to install Class::C3 and optionally MRO::Compat. MRO::Compat does what its name hints; it allows your code to enable C3 MRO on older Perl using the same syntax as what is offered in newer Perls. However, I have found that using C3 MRO in older Perls can cause a significant performance less. This seems to be due to needing to call Class::C3::initialize() after defining a class so that it can re-write the symbol table. If you have a lot of classes that rely on the C3 MRO you will acquire a substantial slowdown in class initialization. I have not looked too hard in to how to tune this (so if anyone has experience here please feel free to contact me) but have instead opted to not use C3 on older Perls.

If you are using Perl newer than 5.9.5 then mro is a core module and you have everything you need. The mro overview says:

The special methods next::method, next::can, and maybe::next::method are not available until this mro module has been loaded via use or require.

Which seems to imply that everything else will just work even without using or requiring mro. However, I found that you have to use or require mro in order to set a class as using C3 (mro::set_mro($class, 'c3')). A trivial issue for sure but worth noting if you get an, Invalid mro name: 'c3', error. An additional feature compared to older Perls is that you do not have to call Class::C3::Initialize() which means that performance does not seem to be an issue at all.

Overall it took just a few lines of code to get C3 support into UR. Now I just need to learn when it is good to use mixing and when it is not.

I semi-frequently have to sudo as another (shared) user to perform some action but whenever I do I am stuck in an unfamiliar Bash and Vim environment. It finally dawned on me that I might be able to load my Bash and Vim settings when I sudo as the shared user. So as of now I have this in the shared user’s .bashrc:

if [ -n "$SUDO_USER" ]; then
    SUDO_USER_HOME=$(echo $HOME | sed "s|$USER|$SUDO_USER|")
    OLD_HOME="$HOME"
    export HOME="$SUDO_USER_HOME"
    source $SUDO_USER_HOME/.bashrc
    export MYVIMRC="$SUDO_USER_HOME/.vimrc"
    export VIMINIT="let &rtp = '$SUDO_USER_HOME/.vim,' . &rtp | source $MYVIMRC"
    PATHOGEN="$SUDO_USER_HOME/.vim/autoload/pathogen.vim"
    if [ -e "$PATHOGEN" ] && grep -q "pathogen#infect" "$PATHOGEN"; then
        export VIMINIT="$VIMINIT | call pathogen#infect('$SUDO_USER_HOME/.vim/bundle')"
    fi
    export HOME="$OLD_HOME"
fi

This is working for one of the shared accounts I use but has some issues with another and I haven’t yet pinpointed the difference. I’ll be sure to update once I have.

Update: I worked out this issue with the original snippet. It now depends (takes advantage of) Pathogen for initializiing Vim.

Update: Fixed another bug; it wasn’t actually sourcing .vimrc.

This is not what “just works” means. Paraphrased here:

1. Install OS.
2. Wireless broken.
3. SearchScour Internet.
4. Using command line interface, extract firmware into specific directory.
5. Wireless not broken.

I understand that the reason the Ubuntu installer didn’t extract the firmware automatically is probably some legal issue (or maybe just philosophical issue). That doesn’t change the fact that this didn’t “just work”.