Tag Archives: everything

Git Weirdness

So I have a git repo on my machine at home, that’s cloned from a repo on git.xfce.org. I was doing some work in it the other day — in a private branch, not published to git.xfce.org — and I wanted to continue working on the private branch from another machine. But… it won’t work. Let’s say ‘machine1′ has the repo with the private branch, and ‘machine2′ is where I want to work today.

So, on machine2, I cloned from the master repo on git.xfce.org:

[brian@machine2 src $] git clone git@git.xfce.org:kelnos/airconfig
[... stuff happens...]
[brian@machine2 src $] cd airconfig
[brian@machine2 airconfig $] git branch -a
* master
  origin/master
  origin/pre-hal

Ok, cool, that’s what I expect. So I ssh over to machine1 (the one I eventually want to pull from), and I check out my list of branches there:

[brian@machine1 airconfig $] git branch -a
  advanced-ip-settings
  master
* nm-frontend
  notification-rework
  reconnect
  origin/master
  origin/pre-hal

Ok, cool. the ‘nm-frontend’ branch is the one I want to pull to machine2. So on machine2, I do this:

[brian@machine2 airconfig $] git remote add machine1 machine1:src/airconfig
[brian@machine2 airconfig $] git pull machine1 nm-frontend
fatal: Couldn't find remote ref nm-frontend
fatal: The remote end hung up unexpectedly

Uh… what? Do I have the wrong syntax? Ok, let me just try to pull everything from the remote:

[brian@machine2 airconfig $] git pull machine1
remote: Counting objects: 1085, done.
remote: Compressing objects: 100% (301/301), done.
remote: Total 1085 (delta 774), reused 1085 (delta 774)
Receiving objects: 100% (1085/1085), 323.43 KiB | 14 KiB/s, done.
Resolving deltas: 100% (774/774), done.
From machine1:src/airconfig
 * [new branch]      advanced-ip-settings -> machine1/advanced-ip-settings
 * [new branch]      master     -> machine1/master
 * [new branch]      pre-hal    -> machine1/pre-hal

And then at the bottom it prints out a message about not knowing which local branches to merge stuff into. That’s fine, no big deal. But… how come it pulled 3 of my local branches on machine1, but left off 2 of them (‘notification-rework’ and ‘nm-frontend’). No combination of src:dest refspecs seem to do the trick. Pulling one of the 3 branches it seems to like using the syntax I used above seems to work fine, but it can’t see the one I want. What am I doing wrong…?

Ruby for Web Development

I recently started a new web dev project, and decided to use it to better learn Ruby. However, I don’t want to use Rails. I’d like to keep it simple. I also prefer to know a lot about the inner workings of a particular technology before I go and use a large framework that hides a bunch of details from me.

However, I want to use ActiveRecord. ORM seems to be all the rage these days, promising to abstract the annoying details of database access behind OO natural for your chosen language. It also helps avoid common errors and pitfalls with regard to constructing SQL queries and the like.

So, ActiveRecord. I install it on my laptop with “emerge ruby-activerecord”, and there I go. One “require ‘activerecord’” in my script later, and, awesome, it starts working.

Then I start working on my web host (DreamHost, if you’re wondering). It can’t find ActiveRecord. But it’s obviously installed, because I know DH supports Rails out of the box, and I don’t think you can have an install of Rails without ActiveRecord. So I poke, and then realise it might be installed as a Ruby “gem.” Ok, so I put a “require ‘rubygems’” above my activerecord require. Nice, now it works. Then I think, well, what if I put this somewhere that doesn’t require rubygems? Not hard to work around automatically:

begin
  require 'activerecord'
rescue LoadError
  require 'rubygems'
  require 'activerecord'
end

Nice, ok, that works. It’s probably a foolish micro-optimisation, but whatever.

Then I notice… ugh, this is super slow. Even on the web host, it can take a good two seconds for the “require ‘activerecord’” statement to execute. Yeah, I know, ruby is kinda slow. But 2 extra seconds each time someone hits basically any page of the website? Ugh.

So…. FastCGI. I know DH supports it, so I head over to the control panel and enable it for the domain I’m working on, and start googling around to figure out how to use FastCGI in a ruby script.

Unfortunately, there aren’t too many resources on this. Fortunately I found a couple sample dispatch scripts, one of which I ended up basing mine off of.

But then there was a problem. Inside my app, I use ruby’s CGI class to access CGI form variables and other stuff. Since the FastCGI stuff overrides and partially replaces ruby’s internal CGI class, there’s a problem. Doing “cgi = CGI.new” inside a ruby script that’s being served through FastCGI throws a weird exception. But I wanted to try to retain compatibility for non-FastCGI mode. And I couldn’t figure out how to get the ‘cgi’ variable from the ruby dispatch script into my app’s script, since I was using ‘eval’ to run my script. The dispatch script I saw used some weird Binding voodoo. Up at the top level we have:

def getBinding(cgi, env)
  return binding
end

I had no idea what that was doing, so I looked it up. Apparently the built-in “binding” function returns a Binding object that describes the current execution context, including local variables and function/method arguments. Ok, that seems really powerful and cool. So I look down to the sample dispatch script’s eval statement, and I see:

eval File.open(script).read, getBinding(cgi, cgi.env_table)

Ok, so it appears it tries to eval the script while providing an execution context that contains just ‘cgi’ and one of its member vars. I only sorta understand this. So I ditched the “cgi = CGI.new” line in my app’s script. But I got a NameError when just trying to use ‘cgi’. Huh? What’s going on? So I get rid of the getBinding() call entirely, and just let it use the current execution context, and suddenly everything works right. Weird.

Well, sorta. Now, remember, I want to preserve compatibility with running as a normal CGI. So the normal CGI needs to create its own ‘cgi’ object, but the FastCGI one should just use the one from the dispatch script. So I came up with this:

begin
  if !cgi.nil?
    mycgi = cgi
  end
rescue NameError
  require 'cgi'
  mycgi = CGI.new
end

Ok, that seemed to work ok. After that block, ‘mycgi’ should be usable as a CGI/FCGI::CGI object regardless of which mode it’s running under.

So I play around a bit more, and suddenly notice that my POST requests have stopped working. I dig into it a bit, and realise that my POST requests are actually just fine. What’s happening is that, somehow, the FCGI::CGI object completely ignores $QUERY_STRING on a POST request, while ruby’s normal CGI object will take care of it and merge it with the POST data variables. You see, to make my URLs pretty, I have normal URLs rewritten such that the script sees “page=whatever” in the query string. So when I did a POST, the page= would get lost, and so the POST would end up fetching the root web page rather than the one that should be receiving the form variables. I’m not sure if this is “normal” behavior, or if the version of the fcgi ruby module on DreamHost has a bug. Regardless, we need a workaround. So I go back to my last code snippet, and hack something together:

begin
  if !cgi.nil?
    if cgi.env_table['REQUEST_METHOD'] == 'POST'
      CGI.parse(cgi.env_table['QUERY_STRING']).each do |k,v|
        cgi.params[k] = v
      end
    end
    mycgi = cgi
  end
rescue NameError
  require 'cgi'
  mycgi = CGI.new
end

Ick. But at least it works.

So far, I’m liking ruby quite a lot. It’s a beautiful language, and seems well-suited for this kind of work, especially since I want to get something that works up and running relatively quickly.

We’ll see, however, how many more gotchas I run into.