# stick in .irbrc
def copy(str)
  IO.popen('pbcopy', 'w') { |f| f << str.to_s }
end

def paste
  `pbpaste`
end

def ep
  eval(paste)
end

Linux with xclip (thanks Bjørn Arild Mæland):

def copy(str)
  IO.popen('xclip -i', 'w') { |f| f << str.to_s }
end
 
def paste
  `xclip -o`
end

A few weeks ago, hakunin ruined my repo-followers-ratio, and in order to restore balance in my soul I now see no other options than to reveal one of the things I’ve been playing with lately: GitHub.js.

It’s not very pretty, not very idiomatic and has a nasty dependency on JS.Class. Please remember that I’m still a novice when it comes to JavaScript, so feel free to fork away and turn this into something usable.

$ irb -rnokogirl
no such file to load -- nokogirl (LoadError)

My head just can’t accept it’s called nokogiri instead of nokogirl. Hopefully, this should teach me:

$ sudo gem install nokogirl
Building native extensions.  This could take a while...

********************************************
It's actually spelled nokogiri, not nokogirl
********************************************

Successfully installed nokogiri-1.2.1
Successfully installed nokogirl-1.0
2 gems installed

$ irb -rnokogirl

********************************************
It's actually spelled nokogiri, not nokogirl
********************************************

>> Nokogirl
=> Nokogiri

I’m also very satisfied with both the design and the concept. You start at the top and read until you reach the bottom. No sidebar. No distractions. The content is king. Black, white and red makes it clean; large fonts and line height makes it readable; narrow width makes the paragraphs look longer.

Still, it’s not perfect. The contrast in the header makes it stand out, almost drowning out the title of the post. The timestamps look like they were just throw on later (they were) and it’s pretty cramped in the “Wall of fame” at the bottom. And I haven’t styled <h4> at all.

Welcome to the new version of judofyr.net! If you’re reading this from your feed reader, please come over and have a look. It’s a lot more cleaner: the title is definitly in focus, the timestamps blend nicely into the rest of the site and it’s a little more colorful with some blue and green.

It’s still not perfect. I’m not totally satisfied with the styling of the sub-headlines and the “Wall of fame” has maybe too low contrast. But hey, I’m a programmer – I’m not supposed to design sites.

So, readers, what do you think of this change? After all, this blog is worthless without you. Better? Worse?

RunAgain = Class.new(Exception)
def fib(i, n = 1, result = 0)
  if i == -1
    result
  else
    raise RunAgain
  end
rescue RunAgain
  i, n, result = i - 1, n + result, n
  retry
end

It was extremely slow (see benchmark at the end of this post) since it has to build backtrace for each raise, but at least it worked! I was proud; very proud. Until I discovered this snippet:

class Class
  # Sweet stuff!
  def tailcall_optimize( *methods )
    methods.each do |meth|
      org = instance_method( meth )
      define_method( meth ) do |*args|
        if Thread.current[ meth ]
          throw( :recurse, args )
        else
          Thread.current[ meth ] = org.bind( self )
          result = catch( :done ) do
            loop do
              args = catch( :recurse ) do
                throw( :done, Thread.current[ meth ].call( *args ) )
              end
            end
          end
          Thread.current[ meth ] = nil
          result
        end
      end
    end
  end
end

class TCOTest
  # tail-recursive factorial
  def fact( n, acc = 1 )
    if n < 2 then acc else fact( n-1, n*acc ) end
  end

  # length of factorial
  def fact_size( n )
    fact( n ).size
  rescue
    $!
  end   
end

t = TCOTest.new

# normal method
puts t.fact_size( 10000 )  # => stack level too deep

# enable tail-call optimization
class TCOTest
  tailcall_optimize :fact
end

# tail-call optimized method
puts t.fact_size( 10000 )  # => 14808                                  

Not only was it faster, you could also drop it in wherever you want. Sweet stuff, indeed. My (failed) attempt was sent to /dev/null immediately…

The Ruby Programming Language arrives

A few months later, I received my copy of The Ruby Programming Language and started reading it. Suddenly, on page 151:

The Ruby Programming Language, page 151, 5.5.4 redo: The redo statement restarts the current iteration of a loop or iterator. This is not the same thing as next. next transfers control to the end of a loop or block so that the next iteration can begin, whereas redo transfers control back to the top of the loop or block so that the iteration can start over. If you come to Ruby from a C-like language, then redo is probably a new control structure for you.

I’ve used Ruby for a long time, still I’ve never heard of redo… Here’s an example from the book:

puts "Please enter the first word you think of"
words = %w(apple banana cherry)
response = words.collect do |word|
  # Control returns here when redo is executed
  print word + "> "               # Prompt the user
  response = gets.chop            # Get a response
  if response.size == 0           # If user entered nothing
    word.upcase!                  # Emphasize the prompt with uppercase
    redo                          # And skip to the top of the block
  end
  response                        # Return the response
end

So I started thinking: The reason I used raise/rescue in my implementation was because I needed the retry-keyword… Maybe… What if?

def fib(i, n = 1, result = 0)
  if i == -1
    result
  else
    i, n, result = i - 1, n + result, n
    redo
  end
end

fib(10000)

Unfortunately, “The redo statement restarts the currentiteration of a loop or iterator”, so it only throws a LocalJumpError. However, don’t forget that we’re dealing with Ruby:

### Everything is possible in Ruby!

define_method(:acc) do |i, n, result|
  if i == -1
    result
  else
    i, n, result = i - 1, n + result, n
    redo
  end
end

def fib(i)
  acc(i, 1, 0)
end

fib(10000)  # Yeah!

The Benchmark

So, how fast is it? Take a look below:

• You can zoom by marking in any of the graphs.
• When you un-tick a graph, mark in the lower graph to zoom in.
• Un-tick everything else than “Redo” and “Iterative” and notice how close they are to each other.
• Look how bad “Rescue” performs,
• and how early “Regular” fails.
• All the code is available at GitHub.

Nifty, eh?

Let’s use Sinatra as an example

Most of them are very similar to Sinatra’s (this is slightly modified for readability, but the idea still applies):

params.inject({}) do |hash, (key, value)|
  if key =~ /\[.*\]/
    parts = key.scan(/(^[^\[]+)|\[([^\]]+)\]/).flatten.compact
    head, last = parts[0..-2], parts[-1]
    head.inject(hash){ |s,v| s[v] ||= {} }[last] = value
  else
    hash[key] = value
  end
  res
end   

Update: As Ryan has written in the comments, I better give some credz to the real author of the snippet above: Sinatra’s nested params implementation was taken from an example posted to the Rack ML by Michael Fellinger (of Ramaze fame). For the background on the patch that went into Sinatra: take a look the ticket over at their bug tracker.

We’re looping through each of the params and doing some stuff if the key includes [something] and therefore is nested. If it’s nested, we need to find the parts:

parts = key.scan(/(^[^\[]+)|\[([^\]]+)\]/).flatten.compact

The first part of the regex matches from the beginning to the first [, and the second matches each of the [parts]. Some cleanup is needed to flatten and remove nils (just try the line in IRB and you’ll see it quickly).

Next up, we’re splitting out the last part, and then comes the inject:

head.inject(hash){ |s,v| s[v] ||= {} }[last] = value  

Here, we’re building a Hash based on the params we’ve already cleaned up and the current param we’re working on. Then, finally, we’re setting the value.

The _why way

All of this makes sense. I wrote approximately the same when trying to cleanup my broken version. However, while I was looking for the way Ramaze did it, I found an excellent link to RedHanded: Injecting a Hash Backwards and the Merge Block. That version is just awesome (this is also slightly modified):

m = proc {|_,o,n|o.merge(n,&m)}
params.inject({}) do |hash, (key, value)|
  parts = key.split(/[\]\[]+/)
  hash.merge(parts.reverse.inject(value) { |x, i| {i => x} }, &m) 
end    

Notice the sweet, micro way to split out the parts: If we got a key like: “first[second][third]” we can simply split by any numbers of [ and ]. Of course, we’re going to fail on stuff like “this]is]really]one]key”, but if you’re writing like that, you deserve it!

Now, the next is what makes this so different and awesome. Let’s look at first part of it:

parts.reverse.inject(value) { |x, i| {i => x} }

We’re reversing it and building it backwards. The inject starts with our original value and then we build our way out by creating Hashes:

parts = ["first", "second", "third"]
value = 123

# first run of inject:
x = 123
i = "third"
return { "third" => 123 }

# second run of inject:
x = { "third" => 123 }
i = "second"
return { "second" => { "third" => 123 } }

# second run of inject:
x = { "second" => { "third" => 123 } }
i = "first"
return { "first" => { "second" => { "third" => 123 } } }

So when we got this little recursive Hash, we need to merge it with the rest. Most of you, including me, would say that it would be a hard task, since we also need to merge it recursively:

params = { "first" => { "second" => { "third" => 123 } } }
current_param = { "first" => { "another" => 456 } }

params.merge(current_param) # fail!
current_param.merge(params) # fail!

Meet the Merge Block

This was the first time I’ve ever heard of the merge block. It’s not even properly documented! But it’s a very simple and very powerful feature: If we get a merge conflict (same keys in both Hashes), it’s calling that block. Easy peasy!

params = { "first" => { "second" => { "third" => 123 } } }
current_param = { "first" => { "another" => 456 } }

params.merge(current_param) do |key, value_from_params, value_from_current_param|
  # key is defined in both params and current_param
  value_from_params.merge(value_from_current_param)
end

# =>
{ "first" => { "second" => { "third" => 123 }, "another" => 456 } }

And in order to merge it recursively, we build the block in advance and pass the block into the inner merge too:

m = proc {|_,o,n|o.merge(n,&m)}
# ...
hash.merge(recursive_hash, &m) 

Shorter? Faster?

I believe the first, natural way is both faster and shorter (if we use the micro splitter), but I still think I’m going to put _why’s version in Camping. Not (only) because it’s _why’s, but also because it’s so wicked awesome and fits perfectly together with the other weird stuff in Camping. Some bytes have to be sacrificed for style; Camping is still far away from exceeding the limit.

If it’s an automatically generated folder, it’s a bit easier, but still quite a few commands:

rake generate_some_docs
git checkout gh-pages
git add .
git commit
git push

It’s even harder if you haven’t created the gh-pages branch yet.

Grancher!

Okey, enter Grancher (yeah, I know, lame name):

# Install:
system('sudo gem install grancher')

# Create a Rakefile:
require 'grancher/task'
Grancher::Task.new do |g|
  g.branch = 'gh-pages'
  g.push_to = 'origin' # automatically push too
  
  g.directory 'website'
end

Do a rake publish and the folder will be copied to the gh-pages branch, committed and pushed. Easy peasy!

Have a look at the documentation which isn’t actually perfect, but should be enough to get started.

Oh, and it’s just a few hours old, so bugs will probably bite you! When they do, please report it at lighthouse.

TootSweet Masyu: Masyu is played on a grid. It has a simple goal: to draw a single nonintersecting loop through all of the circles in the grid.

The masyu grid contains two kinds of circles. Each adds a constraint to the path of the loop.

Masyu is a type of logic puzzle designed by the same guys behind Sudoku. Needless to say, it’s very fun and extremely addicting. Especially when you play it on your iPoid, thanks to TootSweet:

Of course, I didn’t like the thought of all those beautiful, hand-made puzzles should be stuck on the iPod, so I wanted to see how they were stored. After SSH-ing to the iPod, a simple find /User/Applications/ -wholename *MasyuBug.app revealed where the files to MasyuBug were stored:

And there, right in Documents was a Puzzles.data. head -c 6 Puzzles.data revealed that it was a SQLite-file and only seconds later I got the schema:

CREATE TABLE properties ( 
  key text primary key,
  value text default null);

CREATE TABLE puzzles ( 
  id integer primary key autoincrement,
  puzzle text,
  name text default null, 
  size integer default 0,
  volume integer default 0,
  board text default null,
  checkpoint text default null,
  status integer default 0,
  solution_date default null);

The puzzles-database looks interesting. Let’s have a look:

sqlite> SELECT id,puzzle,name,board,status FROM puzzles LIMIT 3;
 id | puzzle     | name    | board | status
  1 | 4:4:AgAQAA | Ladybug | ww:gq | 2
  2 | 4:4:CCQQQA | Aphid   | AA:IC | 1
  3 | 4:4:gAAECA | Cicada  | AA:AA | 0    

After some testing with UPDATE-statements I assumed this:

• Puzzle contains the size and the puzzle
• Board contains the current lines
• Status: 2 = solved, 1 = started, 0 = not started

The Puzzle

So I decided I wanted to crack the puzzle-field first and filled the field with various data:

• AAAAAA = empty board
• BAAAAA = white circle in top-left corner
• ABAAAA = the white circle moved three squares right
• AABAAA = the white circle moved three squares right (wrapped by the 4×4-board)
• AAABAA = the white circle moved another three squares right

Obviously, each letter represented three squares, but what do they mean? After 52 UPDATE’s I ended up with this table:

Can you spot how TootSweet’s converts letters to circles? It took me a while, but suddenly I realized it: it’s base-4. It’s in fact reversed base-4 where 0 and 3 = blank, 1 = white and 2 = white. Let me show you two examples:

The letter S is in the 18th position of our table (starting from zero), and 18 is 102 in base-4. Reverse it and you’ll get 201: One black, one blank and one white.

The letter X is in the 23th position, and 23 is 113 in base-4. Reverse it and you’ll get 311: One blank, two whites.

Ruby version:

ALPHA = ('A'..'Z').to_a + ('a'..'z').to_a
def letter(l)
  num = ALPHA.index(l)
  num.to_s(4).rjust(3, '0').reverse.split('').map{ |x| x.to_i % 3 }
end

The Lines

Let’s see how TootSweet’s stores the lines you’ve drawn. I started drawing lines in the app and watched how the board-field changed:

• AA:AA = no lines
• The first two letters changed when I draw a horizontal line
• The last two letters changed when I draw a vertical line
• The first letter changed when I draw a line on one of the six first places.
• Same with the second

It made sense that each letter represented six lines. And, since I knew how TootSweet rolls, it made even more sense that it’s reversed base-2. I had to extend the ALPHA-list, since it needed 64 (2 ** 6) letters to represent every possibility from 000000 to 111111, through some more drawing on the iPod it turned out I just had to append 0 to 9 and + and /.

Example

0 is in the 52nd position of our new table (starting from zero), and 52 in base-2 is 110100. Reversed it’s 001011 and it would look like this (if we assumed that the 0 was in the first letter):

Ruby version:

ALPHA = ('A'..'Z').to_a + ('a'..'z').to_a + ('0'..'9').to_a + %w(+ /)
def line(l)
  num = ALPHA.index(l)
  num.to_s(2).rjust(6, '0').reverse.split('').map { |x| x.to_i }
end

Don’t be evil, please

I reengineered this just as a challenge. It was a lot of fun. However, if you ever want to write Masyu application, don’t steal TootSweet’s hand-made masyus. I’m sure they’ve spent a lot of time on this, and beside, it’s boring to solve the same puzzle twice.

What you could use this information to, is importing puzzles from people’s iPhones, so they can continue to solve the puzzle on their computer. Or, you can store your own puzzles in this format and this can end up as the standard way to store Masyu puzzles. Even though it’s a bit cryptic, the puzzles are quite small when they’re stored this way, and can then easily be shared over IRC and forums.

We’ll see if I ever will use this…

module                    Morse

 A,B,C=proc{M.tr(' ','').gsub(/#{$/}+/,$/).split($/).map{|x|
x[/(.)(.+)(.).*\1\2\3/,2].to_i(16)}},proc{|c|A[][c-65].to_s(2
    )[1..-1].tr('10','-.')},proc{|m|(A[].index(("1"+m.tr(
              '-.','10')).to_i(2))||return)+65}              

def                  self.encode(str)
         str.upcase.split(//).map{|c|(65..90)===
      (c=c[0])?B[c]:c==32?'|':nil}.compact.join(' ')
                                                          end

def                  self.decode(str)
 str.split(' ').map{|m|m[0]==?|?' ':(m=C[m])&&m.chr}.join
                                                          end

                   self.methods(false).
               map{|m|class<<self;self;end.
            send(:define_method,m+"_file"){|f|
      File.readlines(f).map{|l|send(m,l)}.join $/}}


M =              <<-'LETS GO MORSING!'
   3DC5D1BBFBE596573E0EE011500C2959ED1469891C5D9120EA8
   D18A6BF9C806A8A15A77A5788575BD18A0233578435B20884FE

                       A1AAAAAA1AA 
                   BCD             BCD
                   123             123
              412C127               140C127
                      87EB9557EB757      

         7103B03517D082301871039DD318B6ABEB04981
         2A44EFBD92A0B694FE1ECC094F42E7F7DF37AF7
         9781      765A3C96E24326A0F58      1764
         2D3C        3399D0D588D492D        3A95
         AB74          D14522116D1          45E3
         6833      7     A807B37     A      F32E
         BD57      4F      C61      EC      613F
         07EF      733E     F     7DEA      540F
         E285      04F691       656291      6595
         85EC      1D8343A     C1D82A1      9F95
         F5A3      7F8D02D25A357BEDC75      4958
         86C8      61F6679FFEB2DF19CEC      8673
         0706      DC3C81C810CBEBA76FC      CC3C 
         32B7      91791ADFE02C7664F6E      7D51
         1111      656B15AA24FF66461FD      1111
         0BD60F270C533AE418A5A99E65950BD26D003CF
         1BC023CDEBA3CE19D0CF7E0B50607C7E19DD396


   11B878DCDAEAE1AE136657420A26AF87356FCD6DA11B80CDD4F
   22C2201C00354CD948A67CAAA92566A7E4515CAADADC8FA01C0
                     LETS GO MORSING!
                                                          end 

• Gash lets you access a Git-repo as a Hash.
• Gash doesn’t touch your working directory
• Gash only cares about the data, not the commits.
• Gash only cares about the latest data.
• Gash can commit.
• Gash will automatically create branches if they don’t exist.
• Gash only loads what it needs, so it handles large repos well.
• Gash got pretty good documentation.
• Gash got a bug tracker.
• Gash is being developed at GitHub.

Let me show you what I mean…

require 'gash'
wiki = Gash.new("~/programming/sources/gash/.git", "wiki")

# See, it doesn't exists yet!
wiki.branch_exists? # => false

# Lets add some files...
wiki["Start"] = "Welcome to this great [[Wiki]]!"
wiki["Wiki"] = "Something everyone can edit."

# And commit them.
wiki.commit("First verision")

# Now it exists!
wiki.branch_exists? # => true

# We can use all the regular Hash-methods too:
wiki.merge!("Start" => "Se our new section: [[Git]]",
            "Git/About" => "An awesome SCM.")

wiki["GitSCM"] = wiki.delete("Git")

wiki.commit("Adding a Git-section")

# And some special methods:
wiki["Git"].tree?                         # => true
wiki["Git/About"] == wiki["Git"]["About"] # => true
wiki["Git/About"].blob?                   # => true
wiki["Git/About"].sha1                    # => "123456789"
wiki["Git/About"].mode                    # => "100644"