Sunday, December 25, 2011

Vim Script

The updated version can be found on github:
https://github.com/GoingTharn/utils

But here it is if you're lazy (but it can't be used w/o git so ...)
import argparse
import os
import subprocess
import sys

def vim_ezadd(gitUrl, bundlePath=None):
    if bundlePath == None:
        if sys.platform == 'win32':
            bundlePath = os.path.join('~', 'vimfiles', 'bundle')
        else:
            bundlePath = os.path.join('~', '.vim', 'bundle')

    tgt = os.path.expanduser(bundlePath)
    start_dir = os.getcwd()
    os.chdir(tgt)
    cmd = ' '.join(['git clone', gitUrl]).split()
    subprocess.call(cmd)
    os.chdir(start_dir)
   
def vim_load_many(urlList, bundlePath):
    for url in urlList:
        vim_ezadd( url, bundlePath)

def main(*args):
    url = args[0]
    vim_ezadd(url)

if __name__=="__main__":
    parser = argparse.ArgumentParser(description="File to add")
    parser.add_argument('--url',  help='Url for the git repo to clone')
    args = parser.parse_args()

    main(args.url)

I hate work (but not working)

And the headline's not even true. I don't hate work; but I hate our IDE.
I just want to use vim, that's all.

I'm late to the party, I'm sure, but if you are unaware, there's a plugin for vim called pathogen.
This thing plays exceedingly well with git; I've been configuring a Mint box for my own devious purposes (purpose: configure a mint box!) and ran into the good ol' problem of "What's the fastest way to configure my environment?"

This is why I use vim - 90% of my configuration is in one .vimrc file I can pass from computer to computer.
The other big chunk that I haven't been able to easily port has been the plugins. I don't use a lot of them but the ones I do use I'd like to use everywhere.

I've approached it in different manners; my last attempt was gitHubbing my plugins folder, but that still requires path management.
I was on the right track, but doing it the wrong way.

Enter Pathogen.
I add a couple of files/subdirectories to my .vim directory, a call to pathogen in my vimrc (call pathogen#infect() ) and now I can install plugins by git cloning into the .vim/bundle directory, and pathogen will do the rest*

So that gets you a little bit; now it's esay to clone into one place and use git as your install tool. Hunky dory. But it doesn't save you that much if it's one machine.
But if you're using a lot of machines, or jump between work and home - look out!
After you clone all the packages you want the first time you run it, you can then grep out the git clone commands:
history | grep 'git clone' >> clonecalls.txt

Now you have a file with all the clone calls.
You're only a hop skip and a jump away from a bash/python script that will run most of it for you, and keep it up to date.

I'll be writing one in the near term and post it to Github and here when it's done.







* running :Helpfiles after installing plugins is necessary as well; you can make pathogen do it in your vimrc but then you're calling it every time you launch vim.

Wednesday, November 2, 2011

Virtualization for the home

Just went through a whirlwind tour of virtualization choices for the home machine - not much is happening yet.

Seems like the choices were Xen by Citrix, VMWare, and VirtualBox. (The Windows 7 Professional and up virtualization is only useful for other windows boxes, and I'm interested in linux as well)
I've some experience with VirtualBox in the past, but it is Oracle tainted now and didn't want to use it. My findings were:
Xen needs to be the host OS - I can't run windows as the host OS and virtualize under it. Being that I still cling to the dream of playing video games on this rig as well, the complications seem to outweigh the Free aspect of the hypervisor. This seems to make a lot more sense if you have a true server you're working on, or can afford to take your system down while you set up the hypervisor OS.

I didn't want to do that because I don't want the downtime.

So, VMWare is the other option if I rule out VirtualBox. Unfortunately, it's $199.
I could evaluate for 30 days, but with a newborn I don't think I'd actually get very far in my evaluation.

So I ended up back at VirtualBox. I have to grudgingly accept it's a pretty good product. Even if you don't jump into any of the oracle tech stack (and I'm not if possible) you can set up virtualization quick and easy.

I'm hoping to set up a solid dev environment for both android and python tinkering; I've been evaluation django and would like to build out the going tharn domain to be something more than a parking lot for two blogs.

So let's see if I can set up a solid Fedora environment to dev and deploy, an ubuntu environment for the darn fun of it all, and a daemon server that will run all my little monsters I develop and deploy.
And all running on Windows 7 because it's ironic and also plays video games.

Thursday, September 29, 2011

I hate you, C++

I've been in a nightmare hellscape at work with my debugging process the last week or two.

Normally it would be something like:

  1. Write terrible, terrible code
  2. Write slightly less bad unit tests that prove terrible code is, indeed, terrible
  3. Improve terrible code to be slightly less terrible
  4. Slightly improve terrible code with an abstraction or two. Realize entire swaths of code are actually just two objects. Refactor.
  5. Fix unit tests to test new refactored, elegant mess. Brag about it on a blog somewhere, impugn others.

This worked so well, until I got to the UI.
Now I have a new test tool to learn along with learning the UI widgets.
I really need test code for my test code.

But no matter, because that's not the worst of it.

The worst of it is I'm passing in a method from python into C++ wrapped in python.
This causes the debugger to (A) not respect any breakpoints whatsover and (B) not raise a python exception, but a cryptic non-helpful "C++ Runtime environment received an irregular blah dee blah" without any sort of exception.

So I've regressed all the way back to commenting out bits of code, surrounding every single statement in its own try/catch, stuff like that.
Debugging with print statements.

Truly a nightmarish hellscape.
Is it a race condition if the side you expect to lose wins every single time?

That's what I was living with today. A message indicating an object was written was beating the write() call finishing in the database.
"C++ error"
"C++ error"
"C++ error"

A few days ago, I had refactored the UI to take advantage of a dispatcher object, so I'd only subscribe to my message server once, instead of opening three subscriptions. I moved the logger to a higher level object.
The logger I use in my exception handling.
"C++ error"
"C++ error"
"C++ error"

I'm beating these bugs by sheer force of brain thought.

An aside, and why I like writing about what I've done in the day, I've come up with some good ideas for work.

  1. see if passing serialized objects instead of where the object lives makes sense - I can just act on it instead of the db row.
  2. write some improved unit tests that call the handlers I pass to C++ in python, so I can breakpoint them and see if anything wild happens
  3. write some exception handlers in their own class with some logger-specific stuff that I can reference across the project


Wednesday, August 24, 2011

Cool idiom someone showed me today

Say you have something like this in your code:

if parrot == "dead":
    parrot.return_to_store()

Depending on the type of string you're testing, often you can do this:
if "dead" in parrot:
    parrot.return_to_store()
This is powerful because when you want to test this function, you can pass it "dead.unittest" and it will succeed, exercising the code.


Naturally, use with caution as if the code shouldn't execute on "undead" you can't use this sort of idiom.

The more I think about it, the more I think this could be considered dangerous; good for some internal uses (e.g. unit tests) but there are tradeoffs; probably doesn't belong in a public facing API.

But I'm posting it anyway because, hey, maybe someone has input. (lol)





Monday, August 22, 2011

nice interface change

Blogger now remembers what mode you were in last when posting. This is helpful, as I never have to see their Compose mode. Whee, I posted here.