Blog von fugaL

Say you're working on a big project. Then at some point you call strftime or maybe ctime and what do you get but a nasty and mysterious SEGFAULT?? What's more you are absolutely sure you have no memory leaks, nothing is wrong with the arguments to the call. Then gdb tells you only that the segfault is happening somewhere deep inside the library call. Furthermore, it works on some platforms but not others, indicating again that memory leak you are sure you don't have. So what do you do but spend three hours tracking down your much doubted memory leak? Well hopefully you find this very post and save those three hours. You see, if time.h is included in another source file, you may have forgotten to include it where you use it. The compiler won't blink an eye. The linker doesn't even complain. Yet somehow it all works dandy until you try it on the TA's computer. So long story short, check your includes.

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.

I also highly recommend enabling 256 colors via Xresources rather than setting TERM=xterm-256color, this will save headache when sshing in from a less fine terminal or when logging in at the console. A quick google turns up plenty of info on how o set your Xresources with one caveat; if you use uxterm like any sane person would, you need s/Xterm/UXterm/. I’ve also found cases where I need xterm as well, so I simply put all three in there to be safe.

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

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.

Edit: The below paragraph is a bit confusing. Keep in mind that to make b think it’s a, you just replace @b@’s guts with those of a, but this only works for the partial at time t₀. So we make a snapshot for reference, and then pull in @b@’s downstream stuff (because we can’t do this after b thinks it’s a).

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:

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

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.

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.

sqlite_fix.rb:

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

Include it at the end of environment.rb. That’s it!

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.

First, do what everyone else tells you, put this in your config/database.yml:
<pre> test: adapter: sqlite3 database: ":memory:" </pre>
Once you got that, you have to have some way of loading the schema into your memory db every time you run the test. I found that the best place to do this is in config/environments/test.rb. If you have an even better place, please let me know.

At first I thought I could just load "#{RAILS_ROOT}/db/schema.rb" and be done with it. Alas, at this point there is no established connection to the db. So we have to modify things in such a way that this cute little command will get run just after establishing the db connection, but before the db is accessed. I did it like so:
<pre> 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 </pre>
Then don’t forget to rake db:schema:dump before running rake test.

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 poststags. 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.

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.

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.

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

No problem, eigenclasses to the rescue! I just add this simple thing (to a lib or just the beginning of my file):

class << Gtk::Widget

  def new *args, &block

    x = super

    yield x if block

    x

  end

end

That’s all, now you can use good ol’ ruby blocks to make GUI programming less obscene.

I’ve often thought about building some killer web app and using advertising and/or affiliate programs to make money off of it. As a user I know how annoying ad-driven applications tend to be. What if the add’s were only relevent to the content of the application? What if they were only presented in a contextual, non-pervasive way? There seems to be a thin line between acceptable ads and annoyances. Unfortunately it’s hard to tell where that line lies. I should think that I could do better than the blatently annoying, but judging by the very small number of not annoying ad-revenue sites perhaps it’s a tough egg to crack. So do you go with a subscription based plan instead? Would people rather pay a fee or see some adds? On the one hand I like the idea of a free service, even if free means a few ads. On the other hand ‘spam’ gives me the willies and I’m not always sure how much better I feel about pay-per-click. Fortunately at the moment I have no killer web app and so the problem lies dormant. Maybe someday there will be a better business model that won’t divide me so.

I once again have a working IMMS system. (Finally!) I’m using MPD for the player, my own imms.rb to talk to IMMS, and a history/queue wrapper client to turn MPD’s playlist into—you guessed it—a history (before current song) and queue (after current song).

This has the downside that your playlist isn’t a comprehensive playlist. So if you use a client where you would select a song you wanted to hear from a playlist you might not find it. Not to mention that would also mess up the IMMS behaviour.

My solution is mpremote.rb (which also needs livesearch.rb) to quickly find songs from the library and enqueue (enter) or jump-to (END) any song or group of songs I feel like listening to.

Eventually I’ll make a qt or gtk version of mpremote to be more like xmmsfind_remote (if you still use xmms I highly recommend it). Hans and I are also currently conspiring to make an even better MPD that will queue and possibly talk to imms itself.

I was doing some research into SVG when I stumbled across this. Pretty darn cool. I had no idea SVG was that powerful.

Argh, for probably the 3rd time now I found myself trying in vain for some time to hunt down that blasted mkmf.rb. For future reference, and for anyone else searching, here it is.

On debian and debian based distros (ubuntu, demudi, etc) to get mkmf.rb for building those neato goodies, just apt-get install ruby-dev.

I was looking for something else, but stumbled across this. (praise google!) It’s pdf slides for a pretty awesome looking presentation on rails and ajax. Just looking through the slides opened my eyes to some pretty neat stuff I had no clue about. It’s got some funny pictures, too. It would be nice to see the actual presentation that went with the slides.

My favorite lesson from it: I didn’t have a clue about rjs templates and returning javascript for ajax calls. I’m excited to put these to use.

I use darcs in my rails apps. The combination of the generator creating several files at a time and not including the logs in the repo makes adding the new files cumbersome after a generate.

No worries! Just add ^log(/|$) to the _darcs/prefs/boring file. Now you can darcs add -r * after generates and rest easy.

I’ve been using quodlibet for a couple weeks now. I actually was introduced to it by my brother Hans some time ago, but it lacked an imms interface so I clung to xmms. Subsequently, xmms managed, in it’s awesome ability to annoy, to drive me away once and for all.

Using quodlibet I now have a couple fun projects ahead of me. First is writing an imms plugin for it. Next is fixing some quirky behaviour involving the play queue. Queue is probably the most awesome media player feature since random/shuffle. It allows you to add specific songs to come next without muddling around with the playlist itself—the playlist can happily remain in random mode or any other mode you can fathom.

Now I describe those queue quirks. If someone wants to tackle them before I get to it, go ahead. Just let me know so I don’t duplicate a work in progress. ;) Both issues seem to arise from the fact that a song in queue is a seperate instance that != the same song in list. This causes problem 1) the playlist doesn’t show the current song as playing or jump to it. Problem 2) likewise, when quiting quodlibet, the queue state, the playlist state, and the current playing song are all saved. However, upon resuming the current song, if derived from queue, fails to register as anything and doesn’t play. I assume this is because song_from_queue != anything_in_list.

There it is! I got the rss up and running. http://von.fugal.net/blog/rss gives you a nice feed of the 10 most recent entries. You can also get a topic-wise feed by simply adding / to the end, or even a list of topics seperated by comma. e.g. von.fugal.net/blog/rss/linux,web

Next task, fix the design!

The BYU Wireless networks require authentication through a website everytime you connect and then some. This can be pretty annoying and slightly less than trivial to automate. So I took a quiet evening and wrote this script to handle authentication without the point-and-click hassle.

byuwireless.rb reads in a yaml configuration file that contains two elements and looks something like this:

username: your username

password: your password

You can edit where it looks for this file in the script, but the default is byuwireless.passwd in the current directory.

The script is really only a shell of a ruby script. Most stuff is done through other tools like grep and wget invoked through backticks.

I decided to give evilwm a try. It’s a decent little manager. There were some things that I just couldn’t live with and some I couldn’t live without. Fortunately, evliwm is so small it lent itself readily to my hacking out the worst offenses. These included:

• Raising a window anytime you move or resize it—I love to be able to move windows underneath other windows.
• Resizing behaviour—It would jump the cursor to the corner of the window when resizing.
• Directional and restrained resizement—or lack thereof

The foremost was fixed just by wraping the offending function call in my own #ifdef RAISE_MOVE (two occurences). Whilst fixing the second, I took it a step further to fix the third, one I might not have thought feasable had I not been dipping in that code already. This direction resizing, for the curious, works by dividing the window into nine squares. Each square on the edge will resize in only that direction, including diagonal for corner boxes. My only remaining complaint is that it doesn’t tile windows. Update: I have come to appreciate the more organic feeling of windows placed unprecisely

Using evilwm has necesitated using a slough of auxilliary programs to do what my old wm (icewm) used to do for me—shortcut keys being one—and I’ve come to think that auxilliary programs is really the way to go. xbindkeys has handled shortcut keys nicely and even works with funky layouts like Khmer!

Anyway, here is the diff to get windows that stay down and directional resizemennt with evilwm.

1. Download the “Linux Binary” j2se jdk from java.sun.org
2. Run the binary
3. mv the resulting jdk directory (e.g. jdk1.5.0) to /usr/local/lib (or /usr/lib if you prefer)
4. `ln -s /usr/local/lib/jdk1.5.0 /usr/local/lib/jdk`
5. Install java-virtual-machine-dummy and make /etc/java-vm look like this (3 lines): `/usr/local/lib/jdk/bin/java` `COMPLIANT`
6. `update-alternatives —config java`
7. `update-alternatives —install javac javac /usr/local/lib/bin/javac 1 —slave javac.1.gz javac.1.gz /usr/local/lib/jdk/man/man1/javac.1`
8. `update-alternatives —config javac`
9. You might need to `ln -s /etc/alternatives/javac /usr/bin/javac`