About a year ago I found this article in which he fought the same fight. He was able to get a working .so file, using the .Net C++ compiler, and offered his binary, but that won’t work for everyone. Specifically, a file compiled with VC7 isn’t usable by VC6 (at least not that I could see).

Anyway, I followed his advice to a point, and then started experimenting. I opened up irb and started poking MKMF to see what I could accomplish. What I finally ended up with is a hacked extconf.rb that can be edited easily to get the library built on your own system. It will work with both VC6 and VC7, by changing one line in the file. Assuming that you have MySQL 4.1 installed in the default location, and you are using VC6, and Ruby 1.8.2 is installed in the default location, you should be able to do this

    ruby extconf.rb
    nmake
    nmake install

and have everything compile and install. Notice that I said should. You should still take a look at the file, near the top, to see if the settings are appropriate for your system.

Once installed, you can use this module directly, or install DBI for that “standard” interface. DBI will use the library you just built and installed, so all you have to do is download the DBI module, then do this

    cd ruby-dbi-all
    ruby setup.rb config --with=dbi,dbd_mysql
    ruby setup.rb setup
    ruby setup.rb install

If you want to install other DBD drivers, add them after dbd_mysql. That should be it.

Here’s the hacked extconf.rb file.

There are only two lines you might need to change, and they are at the top of the file with comments around them.

I have tested this slightly using the binary I built with VC6 and it seems to work fine. I have not tested the VC7-compiled binary, because I don’t have a Ruby distro that was compiled with VC7. Let me know if these directions don’t work for you. Not that I can do anything about it, but I could put a note here for others.

Also, notice that I used 8.3 pathnames, which is really ugly. I would have been happy to use the pathnames with spaces, but VC6 doesn’t like spaces in pathnames. VC7 can grok them fine, but not 6. Both understand the 8.3, so it was just easier to use that.

One more thing. I don’t believe that installing Visual Studio.Net installs the necessary header and library files for building non-.Net binaries. IOW, you might not have windows.h which will cause things not to work. If you download and install the Platform SDK, then you’ll be fine. My extconf.rb will add the default Platform SDK directory to the necessary paths, so if you have that installed, and try to do a VC7 build, you should be ok.

Our first meeting will be Tuesday March 30 at 7:00 PM. The meeting location is at my office in Norcross, on Peachtree Industrial Blvd. There is a map on the website. We have classrooms, so it will be a comfortable environment.

This meeting will be a "get to know each other" type meeting where we can discuss what, if anything, we've done with Ruby so far. I will then present the first part of an introduction to Ruby, and then discuss the future direction of the group. The meeting should be finished at 8:30 PM.

Things we need to discuss are meeting frequency, topics, presenters and commitments from group members as far as attendance goes. I'm not suggesting that everyone must commit to being at every meeting, but with a small group, if several people miss each meeting, there won't be much "group" to the group, if you know what I mean. As for frequency, I'm currently thinking a meeting every other month (6 per year) but I'm open to suggestions.

Anyway, Sams Publishing has agreed to send me a few copies of The Ruby Way and Teach Yourself Ruby in 21 Days, so I will have those to hand out. (The Ruby Way is an excellent book [thanks, Hal]; I haven't seen the 21 Days book.) I will provide drinks and some snacks for the first meeting, but if we decide to have food at subsequent meetings, then we need to also decide how we are going to pay for it. Lots to discuss, eh?

So, be sure to mark Tuesday, March 30 on your calendar as we kick off the Atlanta Ruby User Group!

SSH_AUTH_SOCK=/tmp/ssh-mjKjm512/agent.512; 
export SSH_AUTH_SOCK;  
SSH_AGENT_PID=1600; 
export SSH_AGENT_PID;  
echo Agent pid 1600;

On a Unix system, it’s easy to capture the output of ssh-agent and evaluate it, but under the ‘command shell’ that ships with Windows systems, which is so pathetically crippled that my old Commodore 64′s BASIC-based shell is looking pretty good, you can’t do that.

So what are those poor saps, myself included, who are using Windows systems to do? Ruby to the rescue. I wrote a simple script that executes ssh-agent, capturing the output, massaging it a little, and then creating a batch file that I can run to set the necessary variables. Simply redirecting the output to a batch file won’t work because there are some Unix-isms, such as exporting the variables, that don’t work on Windows. So, here’s the script:

1
2
3
4
5
6
7
8
9
10

#!ruby   
lines = %x{ssh-agent}   
File.open("c:/tmp/sde.bat", "w") do |file|   
  lines.each do |line|   
    chunks = line.chomp.split ';'   
    if chunks[0] =~ /^SSH/  
      file.puts "SET #{chunks[0]}"  
    end  
  end  
end

You can see that the script sends the captured and massaged output to a batch file called “sde.bat” located in C:/tmp. You can change both of these to suit your preference. Once the script runs, I simply execute the generated batch file and then run ssh-add. The nice thing about the generated batch file is that it lingers until the next time I run the Ruby script. Thus as I open new console Windows I can re-run it to get the environment variables set properly in each one.

  1  class Mixer  2      private  3      def randomize(str)  4          if str.length < 4  5              return str  6          end  7  8          letters = str.split(//)  9 10          first = letters[0] 11          mid = letters[1..(letters.length - 2)] 12          last = letters[letters.length - 1] 13 14          new_letters = "" 15 16          while mid && mid.length > 0 17              len = mid.length 18              r = rand(len) 19              new_letters << mid.delete_at(r) 20          end 21 22          first + new_letters + last 23      end 24 25      public 26      def mix_file(filename) 27          lines = IO.readlines(filename) 28 29          mix_lines(lines) 30      end 31 32      def mix_string(str) 33          new_str = "" 34 35          mix_lines(str.split).each do |line| 36              new_str << line 37          end 38 39          new_str 40      end 41 42      def mix_lines(lines) 43          lines.collect! do |line| 44              new_line = "" 45 46              line.split(/\s+|,|\.|\!|\(|\)|\"|\'/).each do |word| 47                  new_line << randomize(word) << " " 48              end 49 50              new_line 51          end 52 53          lines 54      end 55  end 

And the unit tests, which don’t actually test anything.

  1  require 'test/unit'  2  require 'mix'  3  4  class MixTest < Test::Unit::TestCase  5      def setup()  6          @mixer = Mixer.new  7      end  8  9      def test_word() 10          x = @mixer.mix_string("testing") 11          puts x 12          assert_not_equal("testing", x, "String not randomized") 13      end 14 15      def test_string() 16          x = @mixer.mix_string("this is a humongous test, dangit") 17          puts x 18      end 19 20      def test_file() 21          article = @mixer.mix_file("testfile.txt") 22          #puts article 23      end 24  end 

I’m sure someone will find this useful… Again, “yeah, right.” Ah well, it was a mildly amusing diversion…

The beauty of Ruby is its simplicity and consistency. With Ruby, I find myself writing code to get the job done rather than to appease the compiler.

So true! Since Ruby is a dynamic language, there are no variable types to declare, no static checking; variables are just slots. The number of lines of Ruby code to do something is far less than the equivalent Java code, and I would argue more readable. You don’t have to jump through hoops to make the compiler happy, you just write your code to do what you need done. That’s it. It’s a beautiful thing.

The fact that regular expressions are baked right into the language is also a giant plus. This is how Perl does it, and Matz basically lifted this approach when he created Ruby. Python‘s regex support is not nearly as nice since you have to create a regex and call methods on it instead of using a regex literal and using special variables to get the groups, etc. Where having baked-in regex support really shines is in not having to escape backslashed atoms in the regex. Regexen in Java are even more difficult to read than usual because every backslash is doubled to keep the Java string parser from barfing on unknown escapes.

 words = IO.readlines("wordlist.txt")  anagrams = Hash.new([])  words.each do |word|     base = Array.new     word.chomp!.downcase!      word.each_byte do |byte|         base << byte.chr     end      base.sort!      anagrams[base.to_s] |= [word] end  # Find the anagrams by eliminating those with only one word anagrams.reject! {|k, v| v.length == 1}  values = anagrams.values.sort do |a, b|     b.length <=> a.length end  File.open("anagrams.txt", "w") do |file|     values.each do |line|         file.puts(line.join(", "))     end end  largest = anagrams.keys.max do |a, b|     a.length <=> b.length end  puts "Total: #{anagrams.length}" # puts "Largest set of anagrams: #{values[0].inspect}" #  print "Longest anagram: #{anagrams[largest].inspect} " #  puts "at #{largest.length} characters each" 

Update: Of course, 10 seconds after uploading the code, I see something I could change. Instead of sorting the anagram hash descending by array length, I could have done the following:

 longest = anagrams.to_a.max do |a, b|     a[1].length <=> b[1].length end 

This will sort and pull the largest one off. The key is bucket 0 and the interesting array is in bucket 1.