Blog von fugaL

CSApprox

Probably the coolest VIm plugin since netrw, welcome CSApprox! Just put this in your .vim/plugin and away you go with completely transparent and automatic 256 color themes for your terminal vim that look amazingly not unlike the GUI versions of those themes. Just make sure your terminal properly reports 256 colors, and that your vim binary is compiled with gui support (debian flavors do this, but apparently not red hat flavors). If either of these are missing it will give you a little message and delay opening vim, if this is a problem you might want to suppress that output.

          Xterm*termName: xterm-256color
          UXterm*termName: xterm-256color
          xterm*termName: xterm-256color

Tricking Darcs, or How to Make a Common Branch

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!).

Some _Times_ You Just Want _Things_

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
                    

Rails :memory: revisited

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

Walls and Blocks and Beasts! Oh My!

Some people were poking around for the beast game on #utah today. So I dug up ye olde code and got it to compile without so much as installing some libs and adding a #include. That’s promising, I haven’t touched that code in 4+ years. Anyway it compiles but when you run it the screen is all garbage. #utah says it probably has to do with sfms. I don’t have a hint of time to do anything with it right now, but here I post it anyway in a darcs repo for the whole world to enjoy.

Some history on the project, you can stop reading now if you hate history. This was the first major thing I ever worked on. Before this it was writing a few graphics routines in BASIC for my friends game “Target”. It was then I drew the best ever 8×8 pixel rendition of an angry green blob. Wish I still had that… Prodding the time machine along… My brother Jacob and I set out to clone our good friend beast around 1997-8 in C++. He did all the work at first, with me watching intently and asking such questions as “what does that do?” and “why do it like that?”. Before the end I was writing as much code as he (or at least so I remember it). We had a good ol’ time playing it. When I returned from my mission in 2003 I did a rewrite to port it to linux using ncurses. At some point I also added some fancy self-preservation AI to the beasts. I’m really not sure if the AI stuff is in this version of the code I dug up; I hope it is.

Rails and SQLite3: Default Values

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

Rails :memory: testing in SqLite

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.

Acts as Dead?

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.

Stick it to 'The Man'

In a world frought with restrictive employment agreements how is a prospective employee to protect himself? I believe the reason there are so many undesirable terms is because job seekers are too eager for that next big break or that shiny big company they can put on their resumé. If the companies couldn’t get any bites on these contracts then they would stop mandating them. It’s up to us as the fresh meat on the market to take a stand and decline oppressive agreements. Patience is key. There are plenty of jobs out there and with enough searching and patience I believe you can find a mode of employ that’s not only unrestrictive but that’s mutually beneficial. Seek out that employer you can build a symbiotic relationship with. Work with someone whose goals and values you can make your own. You will be much happier. As such you will be more productive and make your employer happier as well. Dare to love your job, not just what you do, but how you do it and under what terms as well.

Why Software Businesses Fail

The economics of software and all things digital are fiercely different from standard physical economics. The new economy is radically different because of the radically different nature of the commodities. In the physical economy even the most abundant commodities can only be sold once by a particular entity. If I have a truckload of dirt and sell it to a landfill, my dirt is gone. If I have a software product I can sell it time and time again and still have the product. This sounds great, right? What a wonderful and magical thing I have! There’s a problem. Before when I sold my dirt it was gone. I had to get more dirt to sell to someone else. The buyer of my first load could sell it to my next customer and undermine my market, but I’m not worried about that because that consumer ‘consumes’ the dirt and can no longer reuse it. However, when I sell my software the customer can use, reuse, and even redistribute the software indefinately. We have producers but nothing is consumed! This notion of consumers is so fundemental to the physical economy it’s no wonder the ramifications have continued to baffle business. Instead of trying to understand the fundemental differences, business has tried with only limited success to apply artificial barriers and rules to make the new system behave like the old. The fathers of Free software and OSS understood these differences early on and see the artificial modifications as a gross perversion of a wonderful new thing. There’s only one missing piece to this new economy. In an economy, work is performed, things traded, and both yourself and society are benefited. Again imagine I have dirt, this time it’s magical digital dirt. Once I have the dirt everyone potentially has the dirt also. I cannot sell the dirt, everyone has it! Some have tried making new dirt to turn a profit. So I make some green dirt in hopes of making some money from it. But again, I can’t sell the dirt because once I make it, everyone has it already! Society advances but leaves me behind. If I am to help myself in this brave new world I must abandon the idea that the dirt has any value in and of itself. If I make new dirt it’s because I need it, not because it can be sold. Some companies partially embrace the idea and take red dirt and blue dirt made by others and combine it to make purple dirt. But the same fallacy holds, they cannot sell the dirt! The only thing to do is to use the dirt. Let’s shift gears now and imagine paint is free and there’s an unlimited supply. To sell the paint would be silly, but professional painters can still make money putting logos on buildings and signs, applying the paint to roadways and fences. Say I’m a painter and a customer wants her fence to glow in the dark. There is no glow in the dark paint. I can develop the paint myself or I can pay a developer to get me the paint. The only catch is I must abandon all sense of ownership of the new glowing paint, as must the developer if I hired one. Whether I’m the developer or the painter (or both) I put in the effort to make glow in the dark paint to please my customers, not to have the paint. This is the fundemental ideal that must be applied to this magical world of 1’s and 0’s in order to have lasting success. You must use, modify, and create software for the sole purpose of pleasing your customers. If you try to make and sell one product you will be left behind in the blink of an eye.