Archive for the ‘JRuby’ Category

So, you have that new and shiny JRuby 1.1 and would like to try it out with rails. Here’s a quickest guide to do so! The guide assumes that you want to use MySQL as the database, and it has already been installed.

First, install the following gems:

• mongrel – simple but powerful web server.
• activerecord-jdbcmysql-adapter – all you need for activerecord on JRuby to talk to MySQL.
• rails – well, the Ruby on Rails proper.

The command line:

   1: jruby -S gem install mongrel activerecord-jdbcmysql-adapter rails

Create a sample rails application with MySQL backend:

   1: jruby -S rails myapp -d mysql

Enter the newly-created “myapp” directory, then modify the config/database.yml. First and foremost, you need to adjust the adapter name, and instead of ‘mysql’ you should specify ‘jdbcmysql’. You might also want to delete the lines starting with “socket:”.

Here’s a simple example for the development environment:

   1: development:

   2:   adapter: jdbcmysql

   3:   encoding: utf8

   4:   database: myapp_development

   5:   username: root

   6:   password:

Now, it’s time to create our database:

   1: jruby -S rake db:create:all

The next step is to create some minimal scaffolding so that you could actually play with some dynamic functionality and database access:

   1: jruby script/generate scaffold post title:string body:text published:boolean

We need to update the database after that:

   1: jruby -S rake db:migrate

And we’re basically done here, just start rails via:

   1: jruby script/server

and point your browser to the:

   1: http://localhost:3000/posts

Enjoy!

This is a quick guide for those, who’d like to run the Rubyspecs with minimal effort. For those who have JRuby repository checked out, the steps are even easier: ‘ant spec’ – and you’ll run all the unexcluded specs against the freshly built JRuby.

1. Pull the Rubinius repository (and you have to have git for that):

      1: git clone git://git.rubini.us/code rbx

2. Alternatively, you could just download the snapshot of the repository in a compressed file. (Look for “snapshot” links at the page).
3. Basically, that’s it for the setup. Now, just run the tests:

      1: cd rbx  # Step into the directory you've created when pulled

      2: bin/mspec -t ruby spec/ruby/1.8 # Run all Ruby 1.8 specs

      3: bin/mspec -t ruby spec/ruby/1.8/core/kernel # Run Kernel specs

      4: bin/mspec -f s -t ruby spec/ruby/1.8 # More verbose output

4. During the execution, the dots will be printed out, and the final summary, but with “-f s” option, the output is much more interesting:

      1: Kernel.proc

      2: - returns a Proc

      3: - raises an ArgumentError when no block given

      4: - raises an ArgumentError when given too many arguments

      5: - returns from block into caller block

So, that’s about it. The rubyspec format is compatible with Rspec, so there should be no major surprises there. More info *is* available at the official page. I’d suggest to start with “Specs – Overview” and explore from there.

The long awaited JRuby 1.1 is finally out. Working on it was fun, much more fun than I expected — so much to do, so many interesting things, so little time! It is a perfect mixture of Java and Ruby, actually improving my skills in both areas.

For me, it all started last Fall, after a couple of very convincing blog posts by Charlie: How Easy Is It To Contribute To JRuby? and Easy JRuby 1.0.2 Bugs. So I started playing with JRuby, looking for things I could fix, and it turned out that the easiest way to get involved is to look at the Rubyspecs and try to pass as many of them on JRuby as possible. I’ve started filing bugs and submitting patches, and eventually become a JRuby core comitter.

And since then, my main focus is on the compatibility with Ruby, on tests and especially the Rubyspecs. Having spent about 10 years in Java SE and Java ME compatibility, it was rather natural choice for me. We now have the rubyspecs nicely integrated into JRuby build, we maintain an exclude list for those specs that currently fail (and for every new failure we have the bug filed), we sync-up with the main rubyspecs repository frequently and contribute new specs back.

Some major things to do in the future: set up the continuous integration runs for rubyspecs, make the rubyspec runs on Windows and fix the specs to work properly on Windows. It is expected that much more effort will be put into Java Integration infrastructure, and we’ll need an extensive set of tests/specs for the area. The barriers to entry are very low now, and it’s very easy to contribute, so consider doing so!

Some random stats: So far, I’ve filed 232 bug reports, fixed 112 bugs and made 195 commits.

On to JRuby 1.1.1!

It was a “JVM performance week” in JRuby-land. It all started when some recent code changes is JRuby caused an interesting performance degradation with JDK6 on multi-core CPUs. See the original post to the [jvm-l] list and extended coverage of what happened on Charlie’s blog. So, while following the discussion and participating, I learned a few new things and got some interesting additional info and links that I’d like to share:

1. Let’s start with basics. John Rose posted a good starting guide for those who’d like to micro-benchmark things on JVM: So You Want to Write a Micro-Benchmark.
2. Performance techniques used in the Hotspot JVM wiki entry with the list of optimizations JVM does, sweet and to the point.
3. Fundamental work by Ulrich Drepper: What Every Programmer Should Know About Memory, a MUST read, but painful
4. Deep dive into assembly code from Java blog post by Kohsuke Kawaguchi, on how to print out the assembly code that JIT is producing.
5. Examining generated code with OpenJDK 7, exciting stuff!
6. Polymorphism Performance Mysteries Explained, the Issue #158 of The Java Specialists’ Newsletter.
7. How fast is Java Volatile? or Atomic? or Synchronized?, with nice charts and comparisons.
8. Escape analysis can help optimize synchronization by Brian Goetz.

Enjoy!

The Rubyspecs, an extensive set of conformance tests for Ruby platform, is a great tool to enforce the compatibility of JRuby (and Rubinius, and IronRuby). But the specs are currently being mostly run on Linux/BSD/MacOS (against Ruby, JRuby, Rubinius), and are rarely (if ever) executed in Windows environment. Until now, that is.

I tried to run them on Windows some time ago and the mspec, the testing framework that powers Rubyspecs, had some issues with Windows paths. Since then, the issues have been resolved and the Rubyspecs are functional on Windows.

I’ve run them against JRuby, found 4-5 bugs right away (crashes in calls that are not supported on Windows even in Matz Ruby), fixed those, and was able to run the specs to the completion! There are couple of hang-ups here and there, and lots of failures due to fact that rubyspecs were never used on Windows and don’t expect Windows-specific behavior.

I guess, that’s the next big thing, to go over all the specs and adjust them to take Windows specifics into account when needed.

To my surprise, Git is becoming one of the most popular source control systems in Ruby community. New blog entries on how to use Git are popping up all over the place and the amount of excitement is just very unexpected. Who would have thought that source control tools might be so exciting! Well, here are my recipes on how to use Git with Ruby/JRuby subversion repositories.

Personally, I started using Git about 6 months ago, since Rubinius is under Git, and I really wanted to get access to “rubyspecs” which are part of Rubinius repository. At first, I really disliked Git just because the command line is rather complicated, and it takes some time to get used to it and to get familiar with basic Git concepts. After a while, I noticed that I started using Git more and more, and slowly but surely the full power of the tool just started to amaze me. Switches between branches are LESS THAN A SECOND, instant access to the entire history, powerful branch merging, git grep, and the list could go on and on.

So I started to think about switching to Git as my main SCM tool, even on projects that are under Subversion. Again, the git svn turned out to be very capable and complete tool, allowing bidirectional access to subversion repository from Git. Basically, git svn allows to clone the subversion repository with ENTIRE HISTORY into Git repository, and the changes to that Git repository can be pushed back to main Subversion one. On top of that, one can use Stacked Git to maintain a series of patches. This is very useful in case when there is no write access to the main repository. So the patches are handled by Stacked Git and are being sent out to the maintainers via email, or attached to the bug reports. And that’s how I worked on JRuby until I got the commit rights:

1. stg pull svn – get the latest sources from the main (svn) repository, this command will first pop all your currently applied patches, get the latest sources, and re-apply the patches on top of them.
2. stg edit – create new patch, provide description
3. hack, hack, hack
4. stg refresh – record the changes into the patch
5. stg export -p – export the patches into standalone files
6. send the patch to the maintainers

It’s sooo much easier to maintain the patches that way rather than just having the diff files flying around. First, the patches are always against the latest sources, and never outdated (well, at least when somebody changes something in the main repository that conflicts with the patch, you’ll see the issue immediately during the step #1 above, and can correct it right away). Second, it’s trivial to push/pop patches, reorganize them, test with and without them, easy to see which ones applied and which ones are not, etc.

For those who are serious on working on some open source project which is currently under subversion, I recommend to investigate git-svn and stgit in more detail.

Now, here are a couple of examples on how to create a Git repository out of public subversion one.

Let’s start with Ruby itself:

git svn clone -Ttrunk -ttags -bbranches http://svn.ruby-lang.org/repos/ruby ruby.git

Warning: This would take about 12 hours to complete! For those who don’t want to wait that long, here’s the repository I’ve already created: ruby.git.tgz (md5sum: 576b5667affe040fd33478ea074c13b8). Think about it, these 60mb contain entire Ruby history! This is LESS than size of subversion’s working copy! I measured the time to switch between Ruby 1.8 and Ruby 1.9 branches, that’s 500.000 lines changed in 2000 files, and it takes on my Ubuntu Linux about  1.5 SECONDS. git-grep of entire 1.9 branch is 0.2 seconds. git-log of entire 1.9 branch is 0.3 seconds, from the very last revision to the revision #1, is 0.3 seconds. What else can I say?

Now, the JRuby repository:

git-svn clone -Ttrunk/jruby -ttags -bbranches http://svn.codehaus.org/jruby jruby.git

If you have commit rights to JRuby repository, just change HTTP to HTTPS. The process would take about 2.5 hours (and I saw reports that it can be interrupted and then resumed too).

Once you have the local Git repository, you’ll probably need to do the following (when your are in the root of the repository) :

   1: git gc --aggressive --prune

   2: (echo; git-svn show-ignore) >> .git/info/exclude

This would compact the repository further, and will set the proper excludes.

This is just a very basic outline of the process, so if you’re interested, do check out the official documentation and feel free to ask questions.

For the past 5 months I’ve been involved in JRuby project, since it’s a perfect match for my interests: great object oriented scripting language on top of powerful Java platform. And so far, I’m enjoying every second of my time with JRuby! So I thought that I might just post this entry and describe how to contribute to JRuby effectively and comfortably, based on experience and what worked for me.

First major rule: Don’t be shy and submit the bug reports. It’s straightforward, just go to the Jira page for JRuby, get the account and follow the “Create a new issue in project JRuby” wizard. Sure, some bugs would have better chances to be accepted and fixed than others. Clear, precise description on what’s going on, with specified environment (which OS, which JRuby version) is always a plus. Short, reproducible test case attached to the bug would be great! Having a patch that fixes the bug is just perfect. History shows that bugs with test cases and with patches are being resolved much faster, which is not a surprise.

Second rule: Talk to core developers in case when you have some problems/issues with JRuby, or even if you just have some questions. And the best way to do that is to hang out on IRC channel #JRuby (more info here). This is probably the most useful way to be involved, since the core developers and many active JRuby users are always there, 24 hours a day. That heavy use of IRC was kind of unexpected for me, I was assuming that most of communication happens over email and thought that IRC is an outdated way to communicate. And I was very wrong. Now, I can’t even imagine how some other open source projects get away without using IRC. Seriously, IRC is the way. But there are also mailing lists if you insist, they are just being used less actively.

Third rule: Get the sources and start hacking. The sources are under Subversion, but many been using git-svn successfully as well. To build JRuby is very easy, just invoke ant, and that’s it. Everything that’s needed for the build is already in the repository, and there is no need to download any 3rd party dependencies. All you really need is the JDK and Ant installed. Once you have the fix, there are couple of ways to test it, to run unit tests via “ant test” and to run “rubyspecs” via “ant spec”. Also, most of the changes should be accompanied by the new unit tests that verify/validate the new behavior.

Probably the easiest way to find stuff to work on is to follow “rubyspecs” and try to make JRuby pass those spec tests that currently fail. The rubyspecs is a set of conformance/compatibility tests currently maintained as part of Rubinius project (to be extracted into stand alone project sooner or later). I’ll probably post more about rubyspecs in the future since for me this is an incredibly important piece of overall Ruby compatibility story. Currently, you can easily see which rubyspec tests are failing with JRuby and hence are excluded, just invoke “ant spec-show-excludes”.

Another great way to help out not only JRuby but other Ruby implementations is to start writing new rubyspecs. The Rubinius folks are very open about that and after few good submissions would probably offer the commit rights.