Daysleeper

Using class instance variable

We all know how evil class variables are, and they are as dangerous as the “three headed dog” at the dungeon and we shall not talk about it.

But they are necessary for many of the thingies ruby does and used extensively.But today we shall not talk about them.

We saw earlier that, although class instance variables are excellent, but not so friendly to use and they make Ruby look like C++(ahem).

Here goes a little hack, that allows you to define class level attributes based on class instance variables. Since, i often use it in rails and they have taken cattr for class level attributes.

class Object
  def self.metaclass; class << self; self; end; end
  def self.iattr_accessor *args
    metaclass.instance_eval do
      attr_accessor *args
    end
    args.each do |attr|
      class_eval do
        define_method(attr) do
          self.class.send(attr)
        end
      end
    end
  end
end

What above code does is, creates those class instance variables at class scope and also creates accessor methods for it, so that it doesn’t have to suck when used from class instances(remember @foo.class.i_am_class_instance_var)

Here is a sample that, shows it in action:

class Foobar
  iattr_accessor :foo
end
Foobar.foo = "Hemant"
p Foobar.foo
lol = Foobar.new
p lol.foo

Did i miss anything? comments?

Light and fluffy logger library for your threaded app

Ladies and Gentleman,

Here is one of the simplest logger library, written in Ruby as a wrapper around cronolog unix logging utility. Sailent features of the thingy are:

• Handles log rotation quite well, because of dependence on cronolog. For daily rotated logs automatically creates a directory structure of the format, YYYY/MM/DD for storing your precious logs.


• Works remarkably well, when multiple threads are trying to log to the same file. Default logger library reportedly locks itself , when shifting logs accessed by multiple threads.


• Performance is almost same as default logger library. Here are my results:
  

    * With Log4u *
       real    0m24.053s
       user    0m21.881s
      sys     0m1.176s
     * With Logger *
        real    0m25.191s
        user    0m23.033s
       sys     0m1.212s
     

Hmm, where do i get it:

svn checkout svn://rubyforge.org/var/svn/patang/branches/log4u

Class Variables in Ruby

Well much has been said about class variables in Ruby and how good and bad they are. When a C++/Java Programmer comes to Ruby, his search of static class variables begin immediately and unfortunately current Text on Ruby seems to suggest that, class variables are apt equivalents of static variables.

Answer is yes and no. When you use class variables, remember they are the same for all instance of the classes, even derived classes will reflect upon the same value and if you modify the class variables in one of those derived classes, it would be changed for all the other classes, which inherit the same parent. Got the picture?

Ok, Here is scary bit of code:

@@avar = 1
class A
  @@avar = "hello"
end
puts @@avar  # => hello

There is nothing special about code, if you look closely, because if you don’t define a class and declare class variables outside class definition, by default it gets hooked into Object class and since all the classes one way or the other end up inheriting from Object class, if you change the class variable declared at Object class scope in any of the classes, it would be reflected back in class variable held by Object class(bullshit, its the same variable)

Often, thats not.. what you want. Enter class instance variables, which are nice and dandy variables.. which are again avaialble to all the instances of the class and if you change the variable in one instance of the class, it would be reflected everywhere. But unlike class variables, they are not inherited.

Without much ado, here the sweet spot:

class A
  @foo = "bar"
  class << self; attr_accessor: foo; end
end
class B < A
end
p A.foo #=> bar
p B.foo #=> nil
B.foo = "blah"
p B.foo #=> blah

The overhead is, if you have to access them from instance methods of classes, then you will have to use self.class.foo

from IRC

you can do:

str.tr('A-Z','0-7') to each A with 0 and so on

random ruby and rails tricks

One shouldn’t be addicted to too many things at the same time.

1. move your static content of your rails application elsewhere:

config.action_controller.asset_host = "http://assets.example.com"

You can go one step ahead and dump all the crap on Amazon and have RESTful sleeps.

 S3 Amazon rails

2. How do your word wrap a large string?

Here are two versions doing that:

    b = "";i=1;a.split(/\s+/).collect do |word| 
      b << "\n" if ( i%7 == 0); b << word +" "; (i += 1);
    end
  

Another version is:

    b = a.gsub(/((\S+\s+){8})/,"\\1\b")
  

3. Custom form builder by Chad Fowler, left my head spinning for a while.

  <% form_for :contact, :builder => TabularFormBuilder do |f| %>
    <%= f.text_field :name %>
    <%= f.text_field :email %>
    <%= f.text_field :phone %>
  <% end %> 
  

And put this in your application_helper.rb file:

  class TabularFormBuilder < ActionView::Helpers::FormBuilder
    (field_helpers - %w(check_box radio_button hidden_field)).each do |selector|
      src = <<-END_SRC
      def #{selector}(field, options = {})
        @template.content_tag("tr" ,
        @template.content_tag("td" , field.to_s.humanize + ":" ) +
        @template.content_tag("td" , super))
      end
      END_SRC
      class_eval src, __FILE__, __LINE__
    end
  end
  

What he doesn't explain is, how it works. Well there is this class 
FormBuilder, that actually generates the HTML tags when used with form_for
syntax. The best part is, we can define your own form builders. 
Now this feature is undocumented so, DHH won't be too happy about it.
And of course, your designer's girl friend will hate your more for this.

So let's get started on this.  field_helpers variable holds the HTML
form helpers provided by rails, you will have to dig into the code
of ActionPack a little to see that.  Now, Chad doesn't think
check_box , radio_button and hidden fields should go into table rows
and hence avoids beautifying the generated HTML tags for that.

%w(check_box radio_button hidden_field) = ["check_box","radio_button","hidden_field"]

once this nuisance out of our way... next couple of lines 
prepare a string for evaluation, which would generate those helper methods.
@template is the current_template, and we are adding tags along with content to it.

Next super important line is:

@template.content_tag("td" , super))

which actually generates td tag and calls super which in effect calls 
the original method that you are overriding here.
So after removing meta_programming crap: you can see the method as:

    def text_field(field,options = {})
      @template.content_tag("tr",
      @template.content_tag("tr",...
      @template.content_tag("td",super))
      ...
  

Next comes class_eval, which basically executes the code string in the 
context of current class, which is TabularFormBuilder

Okay, next comes ability to utilizes model generated error messages in your form:

You will have to slightly change your Form builder code for that:

    @template.content_tag("td", super + options[:append].to_s + error_message_on(@object, field, options[:label] || field.to_s.humanize)))
  

Another gem of a method is this:

    def tabular_form_for(name, object = nil, options = nil, &proc)
      concat("<table>" , proc.binding)
      form_for(name,
             object,
             (options||{}).merge(:builder => TabularFormBuilder),
             &proc)
      concat("</table>" , proc.binding)
    end
  

It uses several of undocumented methods. calling

",proc.binding) 
  

makes sure that, context witin which the block was defined is preserved.
so calling:

    concat("<table>",proc.binding)
  

would generate:

    <%= "<table>" %>
  

Then question arises, then why waste time and energy with

proc.binding

,

why not just do 
 <%= "<table>" %> 
. 
The reason is, concat is the only
way to output text within a block.

If you see source code of concat method if would become a little more clear:

    def concat(string, binding)
       eval(ActionView::Base.erb_variable, binding) << string
    end
  

so normally form_for which accepts a block/proc, we convert the block to 
proc and pass it to form_for for execution.

So finally the view would like this:
  
    <html>
      <head>
        <%= stylesheet_link_tag "application" %>
      </head>
      <body>
        <% tabular_form_for :contact do |f| %>
          <%= f.text_field :name %>
          <%= f.text_field :email %>
          <%= f.text_field :phone %>
        <% end %>
      </body>
    </html>
  

Monads in Ruby

Monads in Ruby:

Monads in Ruby

Ruby Conf 2006

Rubyists from around the world are meeting up for RubyConf 2006, I can’t help feeling a little sad, about not being there.

No green threads in Ruby2.0

Nick Sieger has published an interview with Matz, on the eve of Rubyconf 2006.
Ruby2.0 will not have green threads and Continuations.

You can read it all by yourself here.

Continuations in Ruby

These days, you hear lots of hue and cry about and how do one go about implementing them.

First question one would ask is, “What are Continuations?”

According to WikiPedia: “In computing, a continuation is a representation of the execution state of a program (for example, the call stack or values of variables) at a certain point. Many languages have constructs that allow a programmer to save the current execution state into an object, and then restore the state from this object at a later point in time (thereby resuming its execution). This technique has been used in functional programming, imperative programming, and message passing programming.”

I hope you get that, if not then fear not continuations are basically a way of returning/saving state of methods.

How?

Let me demonstrate:

def foo; return 666; end;

So, this function returns the value to the calling function, but what if we can pass where to return the call as an argument to the method:

def foo data,cont
  cont rand(data)
end

I guess, that would be the gist of the matter, so in short an continuation never returns. Many people also like to see as gotos.
Whatever the thing:

Shamelessly stolen from ruby-docs here is the code that demonstrates continuations in Ruby:

arr = [ "Freddie", "Herbie", "Ron", "Max", "Ringo" ]
callcc{|$cc|}
puts(message = arr.shift)
$cc.call unless message =~ /Max/

So, what exactly is it doing? Well line #1, creates an array and second line creates a continuation object that can be passed around for calling a method. So, whenever you do call on a continuation object then the execution starts from the end of the block and hence you see loop here, even though none exists.

Which Method called current method

Which Method Called current Method

I really wanted a way to determine, which method has called current method, for aiding in debugging purpose. Here is the way to do it in correct way finally:

def caller_method_name
    parse_caller(caller(2).first).last
end
def parse_caller(at)
    if /^(.+?):(\d+)(?::in `(.*)')?/ =~ at
        file = Regexp.last_match[1]
        line = Regexp.last_match[2].to_i
        method = Regexp.last_match[3]
        [file, line, method]
    end
end