Code Experiments in Ruby

I'm getting this error when trying to use the libmemcache-client-ruby1.8 on Debian Squeeze.

/usr/lib/ruby/1.8/memcache.rb:24:in `read': No such file or directory - /usr/lib/ruby/1.8/../VERSION.yml (Errno::ENOENT)

To troubleshoot, I'm updating ruby1.8. Ugh, now I no longer have irb1.8!!

Oh well, in the end I just edited /usr/lib/ruby/1.8/memcache.rb and changed line 24:

#  VERSION = begin
#    config = YAML.load(File.read(File.dirname(__FILE__) + '/../VERSION.yml'))
#    "#{config[:major]}.#{config[:minor]}.#{config[:patch]}"
#  end
VERSION = '1.5.0'

I have no idea why this bug fix works, but it does. When I run tidy_ffi via a Unicorn, a Sinatra app, and Rack-XSLView manually, it works fine. If I run it via daemontools, it returns an empty string because for some reason LibTidy.tidyReleaseDate isn't return a date!

@@ -76,12 +76,7 @@ class TidyFFI::Interface

   def tidy_buf_object
     @tidy_buf_object ||= begin
-      release_date = Date.parse(LibTidy.tidyReleaseDate) rescue nil
-      if release_date && (release_date > Date.parse("Dec 29 2006"))
-        TidyFFI::LibTidy::TidyBufWithAllocator
-      else
-        TidyFFI::LibTidy::TidyBuf
-      end
+      TidyFFI::LibTidy::TidyBufWithAllocator
     end
   end

UPDATE: This wasn't the end of it. I submitted the fix to libc (Eugene), and he said the check was needed for Mac OS X which ships with an older version of libTidy. I dug deeper, and found that the date was getting returned, but it just wasn't getting processed correctly. After that, I did some external troubleshooting, and found that in irb1.9.1 I had to require 'date' to parse the date libTidy was returning. I switched out require 'rubygems' with require 'date', and the bug went away. Yay!

I got this error today when trying to run a Sinatra web application. Not sure what the root of the problem is, but I found a workaround:

sudo gem1.9.1 install activesupport --version 2.3.5

$ sudo gem uninstall activesupport

Select gem to uninstall:
 1. activesupport-2.3.5
 2. activesupport-2.3.8
 3. All versions
> 2   

For reference, the full error:

/var/lib/gems/1.9.1/gems/deprecated-2.0.1/lib/deprecated.rb:176:in `instance_method': {:metaclass=>:singleton_class} is not a symbol (TypeError)
    from /var/lib/gems/1.9.1/gems/deprecated-2.0.1/lib/deprecated.rb:176:in `block in <top (required)>'
    from /var/lib/gems/1.9.1/gems/activesupport-2.3.8/lib/active_support/core_ext/object/metaclass.rb:13:in `<class:Object>'
    from /var/lib/gems/1.9.1/gems/activesupport-2.3.8/lib/active_support/core_ext/object/metaclass.rb:3:in `<top (required)>'
    from /var/lib/gems/1.9.1/gems/activesupport-2.3.8/lib/active_support/core_ext/object.rb:5:in `require'
    from /var/lib/gems/1.9.1/gems/activesupport-2.3.8/lib/active_support/core_ext/object.rb:5:in `<top (required)>'
    from /var/lib/gems/1.9.1/gems/activesupport-2.3.8/lib/active_support/core_ext.rb:8:in `require'
    from /var/lib/gems/1.9.1/gems/activesupport-2.3.8/lib/active_support/core_ext.rb:8:in `block in <top (required)>'
    from /var/lib/gems/1.9.1/gems/activesupport-2.3.8/lib/active_support/core_ext.rb:8:in `each'
    from /var/lib/gems/1.9.1/gems/activesupport-2.3.8/lib/active_support/core_ext.rb:8:in `<top (required)>'
    from /var/lib/gems/1.9.1/gems/activesupport-2.3.8/lib/active_support.rb:56:in `require'
    from /var/lib/gems/1.9.1/gems/activesupport-2.3.8/lib/active_support.rb:56:in `<top (required)>'
    from /var/lib/gems/1.9.1/gems/mail-2.2.1/lib/mail.rb:6:in `require'
    from /var/lib/gems/1.9.1/gems/mail-2.2.1/lib/mail.rb:6:in `<module:Mail>'
    from /var/lib/gems/1.9.1/gems/mail-2.2.1/lib/mail.rb:2:in `<top (required)>'
    from /var/lib/gems/1.9.1/gems/pony-1.0/lib/pony.rb:2:in `require'
    from /var/lib/gems/1.9.1/gems/pony-1.0/lib/pony.rb:2:in `<top (required)>'
    from /home/albertlash/svxbox/lib/svxbox/ponyboy.rb:6:in `require'
    from /home/albertlash/svxbox/lib/svxbox/ponyboy.rb:6:in `<top (required)>'
    from /home/albertlash/svxbox/lib/svxbox.rb:8:in `require'
    from /home/albertlash/svxbox/lib/svxbox.rb:8:in `<top (required)>'
    from /home/albertlash/yodnsconf/yodnsconf.rb:45:in `require'
    from /home/albertlash/yodnsconf/yodnsconf.rb:45:in `<top (required)>'
    from config.ru:11:in `require'
    from config.ru:11:in `block in <main>'
    from /var/lib/gems/1.9.1/gems/rack-1.1.0/lib/rack/builder.rb:46:in `instance_eval'
    from /var/lib/gems/1.9.1/gems/rack-1.1.0/lib/rack/builder.rb:46:in `initialize'
    from config.ru:1:in `new'
    from config.ru:1:in `<main>'
    from /var/lib/gems/1.9.1/gems/unicorn-0.99.0/lib/unicorn.rb:46:in `eval'
    from /var/lib/gems/1.9.1/gems/unicorn-0.99.0/lib/unicorn.rb:46:in `block in builder'
    from /var/lib/gems/1.9.1/gems/unicorn-0.99.0/lib/unicorn.rb:816:in `call'
    from /var/lib/gems/1.9.1/gems/unicorn-0.99.0/lib/unicorn.rb:816:in `build_app!'
    from /var/lib/gems/1.9.1/gems/unicorn-0.99.0/lib/unicorn.rb:673:in `init_worker_process'
    from /var/lib/gems/1.9.1/gems/unicorn-0.99.0/lib/unicorn.rb:688:in `worker_loop'
    from /var/lib/gems/1.9.1/gems/unicorn-0.99.0/lib/unicorn.rb:605:in `block (2 levels) in spawn_missing_workers'
    from /var/lib/gems/1.9.1/gems/unicorn-0.99.0/lib/unicorn.rb:602:in `fork'
    from /var/lib/gems/1.9.1/gems/unicorn-0.99.0/lib/unicorn.rb:602:in `block in spawn_missing_workers'
    from /var/lib/gems/1.9.1/gems/unicorn-0.99.0/lib/unicorn.rb:598:in `each'
    from /var/lib/gems/1.9.1/gems/unicorn-0.99.0/lib/unicorn.rb:598:in `spawn_missing_workers'
    from /var/lib/gems/1.9.1/gems/unicorn-0.99.0/lib/unicorn.rb:612:in `maintain_worker_count'
    from /var/lib/gems/1.9.1/gems/unicorn-0.99.0/lib/unicorn.rb:408:in `block in join'
    from /var/lib/gems/1.9.1/gems/unicorn-0.99.0/lib/unicorn.rb:396:in `loop'
    from /var/lib/gems/1.9.1/gems/unicorn-0.99.0/lib/unicorn.rb:396:in `join'
    from /var/lib/gems/1.9.1/gems/unicorn-0.99.0/lib/unicorn.rb:28:in `run'
    from /var/lib/gems/1.9.1/gems/unicorn-0.99.0/bin/unicorn:126:in `<top (required)>'
    from /var/lib/gems/1.9.1/bin/unicorn:19:in `load'
    from /var/lib/gems/1.9.1/bin/unicorn:19:in `<main>'
I, [2010-05-28T04:48:24.242011 #28838]  INFO -- : reaped #<Process::Status: pid 28848 exit 1> worker=0
I, [2010-05-28T04:48:24.242246 #28838]  INFO -- : master complete

Earlier this week I can across a bug like none I'd ever seen before. The bug is causing tidy_ffi to fail in its efforts to tidify a string when daemontools is running the Unicorn process, whereas it works fine if my user (or root) runs the process.

At first I thought it was an environment variable missing, causing the string encoding to get messed up, but alas, no, that's not the problem.

I checked and set most of the environment variables, including LANG, then debugged the process by putting the encoding name out. They were the same if I was running the process or if daemontools was running it.

Anyone have any idea why this might happen?

UPDATE: I found a solution, but I still don't know why this was happening:

Strange Fix for the Strangest Bug

I'm making some modifications to a fork of a gem which I offers the functionality I'm looking for but lacks configuration capabilities I need.

I found that the gem uses Ruby's autoload mechanism, which I've read is a good thing, but the paths it was using messed me up.

This is what I've changed to make it work for me:

5,6c4,5
<   self.autoload :LibTidy, File.dirname(__FILE__) + '/tidy_ffi/lib_tidy'
<   self.autoload :Interface, File.dirname(__FILE__) + '/tidy_ffi/interface'
---
>   self.autoload :LibTidy, 'tidy_ffi/lib_tidy'
>   self.autoload :Interface, 'tidy_ffi/interface'
9,11c8,10
< require File.dirname(__FILE__) + '/tidy_ffi/options_container'
< require File.dirname(__FILE__) + '/tidy_ffi/tidy'
< require File.dirname(__FILE__) + '/tidy_ffi/tidy_ffi_extensions'
\ No newline at end of file
---
> require 'tidy_ffi/options_container'
> require 'tidy_ffi/tidy'
> require 'tidy_ffi/tidy_ffi_extensions'
\ No newline at end of file

• http://www.subelsky.com/2008/05/using-rubys-autoload-method-to.html

I'm porting Chimailmadmin, an email management tool I've been working on for a couple of years, to Sinatra.

Actually I'm working on porting a bunch of web applications I work on, but Chimailmadmin is the furthest along.

I'm glad I held off for a bit while I became more familiar with Sinatra. Its a really sweet little web application framework.

And yes - its open source (Affero GPLv3) and available on Github!