Utah Open Source Planet

Please, Von, please, next time you set up a samba mount, just use cifs and not smbfs. Save yourself a lot of headache.

Imagine you have a repository. At time t₀ someone copies the code from the repository, starts another repository from there, and commences development. You also continue development. At time t you want to pull in the changes the other guy has made.

One approach could be you simply merge other guys code into yours with one big commit calculated from time t₀. Now suppose you want to keep other guy’s history from t₀ on, or even worse, you want to pull only some changes and you want to push some of your changes to other guy.

This is a true story. It all started with CVS. A webapp was developed, cloned and branched. Now there are 4 of them, mostly the same, but subtly different, and each with it’s own CVS repo. Each one at some point in time is identical to another, but the history behind those points in time are different, thanks to copy and commit cloning.

So after converting the CVS to Darcs, I came up with a way of tricking darcs into treating time t₀ in each repository as the same t₀, thus enabling cross-pollination, and here I describe that method.

First you find t₀, and tag liberally. By liberally I mean twice. I’ll explain why later. Of course you put the same two tags on both repos, both at the same point in time. Then you do a darcs opt --checkpoint on each so you can do a partial get on them.

Now you have to decide which repo you’re going to keep, and which one you are bringing in. You probably want to keep the one with past history, and bring in the one that did copy and commit cloning. Do a darcs get --partial on each repo, keeping track of which is what. I like to use a for the destination, and b for the bad repo.

Now go into b/_darcs and we’ll play around with these guts to make it think it’s a, but we want it to have it’s future patches first. So we take a snapshot before pulling the other stuff. I just made a temp directory and did cp -r inv* patches temp, these are the three things in the _darcs directory we care about. Here’s where the liberal tagging comes in, the partial at the later tag only depends on the first tag, so that makes your inventory and patches much simpler. Now you’re ready to pull in all the subsequent patches from the cloned branch.

Once that’s done, you go back into b/_darcs, this time you take anything in temp/patches and temp/inventories and remove the corresponding files from patches and inventories. Then you replace those files with the files from a/_darcs/{inventories,patches}. These two steps I accomplish like so:

ls temp/inventories | while read i; do rm inventories/$i; done

ls temp/patches | while read i; do rm patches/$i; done

for f in inventories patches; do cp ../../a/_darcs/$f/* $f; done

One last step remains. Now you edit inventory and replace that very first patch number, the one that’s a tag, with the one that’s in the inventory file from a. Now b effectively has the exact same past history as a, and has all it’s future patches, and now you can share between your repo and other guy’s repo freely.

One might think this is an uncommon situation, but I can’t help but think it’s more common than I think… Hopefully this guide will save others the headache of trying to wrap their minds around the darcs inner guts, as well as save me some headache should I ever encounter this again (which I’m pretty sure I will, in only a few weeks!).

Working on an AES implementation in ruby, I’ve had many occasion to do:

n.times {|i| some calculations based on i}

I’m sure many of you have used the Integer#times method much to your glee. I’m sure many of you have also had the occasion where you realize that you want those resultant calculations to end up in an array of some sort. At this point you have two options: create an array before hand and << those results in, or change your iterator to (0...n).map {|i| ...}. Both options are severely lacking in taste, IMO. So I came up with a third option. Enter Integer#things.

ary = n.things {|i| ...}

Notice how the syntax here remains consistent with the semantics. Before you wanted to do something n times. Here you want the same, but you want to store the results, you want n results, or n things.

Don’t get me wrong, I love Range and it certainly has it’s place. I would never argue that 26.things { make a letter } is a better approach than ('a'..'z') { just have your letter already }. Like I said, it’s about semantics, do you really want that range or is it more about the number of things? And as we all know deep down, the syntactics should match the semantics wherever possible.

So here is my implementation for Integer#things and I really hope something like this becomes included in future ruby.

                  class Integer
                    def things &b
                      b ||= proc {|i| i}
                      ary = []
                      times do |i|
                        ary << yield(i)
                      end
                      ary
                    end
                  end
                  

As I was creating a new rails app, I used this previous post of mine to set up the in memory database. Well it’s time for an update. Apparently now the rails config/environments/*.rb are run in the context of Rails::Initializer. So instead of creating that context as in the previous post, you simply do:

        alias initialize_database_old initialize_database
        def initialize_database *args
          initialize_database_old
          load "#{RAILS_ROOT}/db/schema.rb" 
        end

I had a chance to try out Leopard over the weekend, and there's quite a bit to like. In the end, though, I restored my backup (which was a lot more difficult than it usually is, but that's another story), and I'll be sticking with Tiger for at least the next few weeks.

I should probably start off by mentioning the good parts. I didn't get to use the system for long, but already I like the ability to use tabs in Terminal, and I can see that Spaces and Time Machine are going to be great. The new dock looks nice, and I'm sure I'm going to like stacks.

I had a few annoyances, too, though, and one complete show-stopper (which I'll save for last).

MySQL

I'm not sure exactly why, but I had to recompile the MySQL server. Not a problem, I do that often enough with new upgrades that I've got my configure arguments saved in a script so it's fairly automatic, but unexpected. The real annoyance here was that MySQL Pref Pane stopped working, and claimed that it wasn't compatible with a PowerPC-based Mac. Odd, I had just been running it on a PPC Mac in Tiger and it worked fine.

That's not a show stopper, since I can still run MySQL from StartupItems and it works fine, but it's a bother not to have it work in System Preferences.

Lighttpd

A long time ago, I switched from the built-in Apache 1.3 in Tiger to my own build of Apache 2.0, and more recently from Apache 2 to lighttpd. I never have had any success with the lighttpd launchd script that shows up all over, but that doesn't matter: anyone who's switched out Apache will have learned that you can replace Apple's default /usr/sbin/apachectl with a symbolic link to your own apachectl script, and your new Apache will magically Just Work with the Personal Web Sharing control in System Preferences. Turns out, that works just fine if your "apachectl" script happens to run lighttpd instead of Apache, too.

Not so in Leopard, unfortunately. I was able to get lighttpd to run from StartupItems, and with a few more days to play with it, I'd probably have had it working in System Preferences too, but not yet. (On the good side, though, Apple has finally switched to Apache 2, so if I were to give up on playing with lighttpd, it would be fairly simple to drop in my Apache 2 httpd.conf and run with the software that comes built in in Leopard.)

PHP

I had to recompile my FastCGI build of PHP. Again, I'm not sure why it stopped working, since it wasn't installed in the same place as Apple's default PHP. Not a serious problem, but a bother.

Terminal

I mentioned before that I really like tabs in Terminal. They don't even begin to make up for Terminal's new window sizing behavior, though.

In Tiger, I can set the size and position of my Terminal window, and once I do, it stays how I set it. That seems fairly obvious. Leopard, unfortunately, missed that obvious behavior. Every time I open a new terminal window or switch between two terminal windows, Leopard's Terminal decides that It Knows Better and moves and resizes my window. That's completely unacceptable, and I was almost ready to go back to Tiger just for that.

Apple has generally done a good job of picking sane defaults for window sizes and locations, but when I put a window somewhere and size it how I want it, I had a reason for doing it, and the system had better respect that. If I weren't already bald, this one would have had me pulling all my hair out within the first five minutes. When (if?) I do switch to Leopard again, I'll be looking for a different Terminal program. Suggestions, anyone?

And finally,

The show-stopper

I really should have checked before trying Leopard, but it never occurred to me. Verizon won't be releasing updated software for my EVDO card until sometime in November, and the old software doesn't work in Leopard. That means, of course, that Leopard is dead in the water until November as far as I'm concerned. Game over.

I'll probably upgrade after the new EVDO software comes out. I'll probably decide I really like Leopard (I already do, in fact, despite the foregoing). I'm thinking I'll do a clean system build rather than try to upgrade, because I've been wanting to re-do the way I've got PHP and a few other utilities installed anyway, and this will be a good chance to start from scratch. But I'm not touching this again without two full backups, and probably not without already finding a good replacement for Terminal.

Here’s another rails fix. This one is for SQLite3 >= 3.3.8. SQLite decided to return sql strings for the default values shown in table definitions. This broke rails, the rails people got mad and won’t introduce a workaround. Well here’s my workaround.

module ActiveRecord
          module ConnectionAdapters
            class SQLiteAdapter < AbstractAdapter
              def columns table_name, name=nil
                table_structure(table_name).map do |field|
                  /^'?(.*)'?$/.match field['dflt_value']
                  field['dflt_value'] = $1
                  SQLiteColumn.new(field['name'], field['dflt_value'], field['type'], field['notnull'] == "0")
                end
              end
            end
          end
        end

I wanted to get that nifty :memory: db thing working for the test database in Rails. There are a sparse few articles floating around telling you how to do this. All of them, IMHO, are kinda ugly, or at least not-so-elegant. Here’s my answer, which took a lot of digging around in the inner workings of rails to come by.

        test:
          adapter: sqlite3
          database: ":memory:" 
        

        module Rails
          class Initializer
            alias initialize_database_old initialize_database
            def initialize_database
              initialize_database_old
              load "#{RAILS_ROOT}/db/schema.rb" 
            end
          end
        end
        

There’s probably other things you could do, like use ActiveRecord::Base.establish_connection instead of Initializer.initialize_database.

I break the above code block into lib/memdb.rb and simply require that inside of config/environments/test.rb. I tried to just add a metaclass to the config variable you see in test.rb but that is apparently some kind of impostor, because it didn’t work. Anyway, armed with this knowledge someone could probably make a pretty sane plugin to cleanly bring you :memory: testing.

Been a while… So my blog was broken just now, not sure for how long. Not more than a month I think. The problem was in the acts_as_taggable plugin, which rumor has it is dead. For now I will still use it, and describe the fix in case it also is broken for you. The problem is in the join table. The geniuses decided to make the join table <tag class>_<taggable class>. This is backwards from the regular has_and_belongs_to_many convention in activerecord. Somewhere, somehow, this backwardsness was reversed. I had it using it’s default join table before (tags_posts) and it broke as now it’s looking for posts_tags. So I add an option to the call:

acts_as_taggable :join_table => :tags_posts

I suppose I could have changed the table name, but at least this way it will never (hopefully) break again. I’m not quite sure how this default behavior changed in the first place.

As I was exploring gtk in ruby I found myself frustrated with the inability to create nested widgets in equally nested code. Such as:

$main = Gtk::Window.new
$main << Gtk::HBox.new do |b|
  b << Gtk::Button.new("click me")
  b << Gtk::VBox.new do |v|
    ... etc etc
  end
end

class << Gtk::Widget
  def new *args, &block
    x = super
    yield x if block
    x
  end
end