JRuby

A friend of mine recently wrote an entry on adding method_missing to Python.   He wrote this because he hung out for 6 hours with three Ruby folks in a car on our way back from PyCon.  We wanted to know if it was possible.    Conclusion: yesThis led ... [More] to a conversation that we had last night:  Is method_missing useful in Python (python people can debate this if they care to)?  This in turn morphed into a conversation about the use cases for method_missing (morphing can happen when having beers).  When is method_missing a useful feature?  This made me think of how we are using it in JRuby.A decent example of method_missing in JRuby is how we resolve Java packages and classes when accessing Java classes.   In Java, there is no convenient or easy way of getting all packages/classes that are accessible by the JVM.  In JRuby, we can also dynamically load jar files (which contain more classes) at any time.  So we have no way of knowing what classes/packages exists and what doesn't at a particular point in time.  method_missing (and const_missing) to the rescue...We define a Package class (this is a simplification of what we actually have, but the basic premise is represented here) which contains a method_missing and a const_missing method.     These methods become responsible for constructing sub-package Package instances and loading Java classes.  Lets look at an example.  Lets say we have an instance of Package called 'java' in our top-scope:java = Package.newNow lets execute the following code fragment:java.util.Hashtable.newWhen 'java' tries to execute 'util', 'util' does not exist as a method.  So off to method_missing we go.  Our Package's method_missing impl will end up constructing a new Package instance called 'util' and add it as a child to 'java'.  Now when this newly constructed 'util' recieves the constant 'Hashtable', 'util' ends up calling 'const_missing' which then calls our Java loading code which tries to retrieve 'java.util.Hashtable' as a Java class.  As a result it loads Java's Hashtable.  ta-da.For Ruby programmers, this example is not very complex, but for the non-Ruby programmers it gives a real-life example of how useful it can be. [Less]

I broke down and created a twitter account.   I never really understood the appeal until recently.  A gigantic global IRC channel where you can take pot shots at each other (yeah I am speaking to John Lam)....Or at least have a very limited exchange ... [More] of ideas.    If you are interested in my voyage of self-discovery:http://twitter.com/tom_eneboEnjoyPS - Just kidding John...but in all seriousness get on irc.freenode.net and talk to #rubinius guys.  They would appreciate it. [Less]

Great news for all Ruby implementations around. A project to bring RbYAML up-to-date and perform better has been accepted for Google Summer of Code. Long Sun is the name of the student, and me and Xue Yong Zhi will jointly mentor this effort.In fact ... [More] , I'm very excited about this news. RbYAML was an incredibly important piece of the puzzle to get JRuby to finally work with RubyGems, and that kickstarted our possibilities to start testing numerous other applications. I soon ported RbYAML to Java, and created the JvYAML and JvYAMLb projects, to get better efficiency. Sadly, this left RbYAML without any TLC. That changed a while back when Rubinius picked up the project to get their YAML support going, and now that Long Sun will work on it, hopefully we will finally get an extremely compliant and bug free YAML implementation for Ruby.This will obviously benefit Rubinius, but it will also be very good for both JRuby and IronRuby. The work will be test-driven which means a more complete test suite will be built around YAML in Ruby.If you're interested in following the project, it's now hosted at Google Code (due to problems with RubyForge from China) at http://code.google.com/p/rbyaml/. Long Sun will also blog about his progress here: http://rbyaml.blogspot.com/.Exciting news indeed. [Less]

Wayne Meissner did some digging and improved our stat performance by creating heap-allocated structures using JNA instead of using JNA's native-allocated versions.  He got this idea from jffi and I am guessing it is faster since it is not doing ... [More] any verification of the data being stuffed into the heap-allocated objects (someone please email me if you have a better explanation).  The bug which started this optimization out is JRUBY-2299.After his initial post for MacOS stat structure I then created versions for Linux and Solaris.  The results are very entertaining (results from test/bench/bench_stat.rb in our project):MacOS             J5client  J5server   J6client  J6serverNative-based 1.40s     0.69s      0.57s     0.57sHeap-based   0.37s     0.27s      0.23s     0.22sSo, stat is almost 4 times faster on Java 5 with the client VM setting.  Amazing!  I kept around the native-allocated versions since I am hoping that later versions of JNA may end up speeding up the native-allocated version (they look quite a bit nicer code-wise).  Even using Java 6 we can see almost a 3x speedup.  The speedup on Linux is virtually identical (omitted for brevity).Solaris held a small surprise.  When I originally made the structure I used a nested struct for timespec - a struct used for holding seconds and nanoseconds for holding atime, ctime, and mtime.  When I made the HeapStruct I just shoved that struct straight into heap structures.  This ended up reducing the Java 6 times form 1.5s down to 0.21s.   500% speedup.One last interesting tidbit about this work.  We have a pseudo-stat structure we construct out of pure Java calls when we are running in an environment where JNA cannot load.  The time it takes to build this structure (on MacOS) is about 0.3s.  So the new JNA versions are about 50% faster than the pure-Java version.  Cool. [Less]

The JRuby community is pleased to announce the release of JRuby 1.1.1!Homepage: http://www.jruby.org/Download: http://dist.codehaus.org/jruby/JRuby 1.1.1 is the first point release of JRuby 1.1.  The fixes in this release are primarily obvious ... [More] compatibility problems and performance enhancements.  Our goal is to put out point releases more frequently forthe next several months (about 3-4 weeks a release).  We want a more rapid release cycle to better address issues brought up by users of JRuby.Highlights:- interpreter method dispatch speedup- reduced memory consumption (permgen)- fixed nasty concurrency bottleneck- stat()/lstat() 300% faster- improved startup time- improved bigdecimal support- 42 issues resolved since JRuby 1.1JRUBY-1628        Compiled ruby programs do not know how to interpret the directoy path in a require statement.JRUBY-2093     JI: matching_method sometimes selects method with wrong arity for overloaded methodJRUBY-2111     test_thread failure in run-junit-compiled-threadpoolJRUBY-2254     Can't run JRuby with GCJJRUBY-2270     Deadlock With ReentrantLock and Java IntegrationJRUBY-2316     Range#step doesn't work with custom object that only respond to #succ, #<=>JRUBY-2330     define_method super very broken at the momentJRUBY-2337     Latest build (6366) jruby.bat does nothingJRUBY-2339     ArrayIndexOutOfBounds running Rubinius bm_glob benchmarkJRUBY-2340     File.open in write mode on read-only files raises Errno::ENOENT, should be Errno::EACCESJRUBY-2343     InheritedCacheCompiler does not use inherited call site fields, causing some permgen wasteJRUBY-2344     static callCount field used for "every 256 calls" thread event polling interferes with parallelizationJRUBY-2345     Marshal.load should raise EOFError if the file to load from is emptyJRUBY-2350     Rbconfig's Config::CONFIG provides non-standard platform namesJRUBY-2352     Various Process methods breaks JRuby hard on WindowsJRUBY-2355     Etc.getlogin blows up JRuby, but works OK in MRI, on WindowsJRUBY-2356     Most of Etc methods (except for getlogin) blow up JRuby on windowsJRUBY-2357     File#truncate blows up JRuby on files from within JAR filesJRUBY-2358     "A = 12; class A::B; end" crashes JRubyJRUBY-2361     Kernel.load and Kernel.require can't handle paths with ~/ and ~username/JRUBY-2362     StringIO#rewind doesn't clear EOF flag, fails new rubyspecJRUBY-2363     Kernel.exit! does not work from within Rails running under WebrickJRUBY-2365     update_rubygems "shebang" points to /Users/headius/NetBeansProjects/jruby/bin/jrubyJRUBY-2367     JRuby 1.1 is not compatible with IBM JDK 5.0 or 6.0JRUBY-2371     src dist is not including RakefileJRUBY-2372     Sample script java2.rb doesn't neccesarily open the correct fileJRUBY-2379     Symbol#inspect fails two new rubyspecsJRUBY-2381     Zlib is *VERY* slow on big files, affects gem installation severely in some casesJRUBY-2385     expect.rbJRUBY-2388     Calling Module.start resolves to org.jruby.RubyGC#start.JRUBY-2390     Input stream not closed in org.jruby.runtime.ConstantsJRUBY-2393     Env.to_hash should return new hash instanceJRUBY-2394     File.stat should follow the symbolic link and report the stat for the file pointed by the linkJRUBY-2397     File#chown and File.chown should allow nil as first argumentJRUBY-2402     Ant build on Windows is brokenJRUBY-2405     Zlib::GzipFile.wrap has bad signatureJRUBY-2406     StringIO.new "", "r " (rb ) is not open for writingJRUBY-2407     StringIO.new does not accept MODE constantsJRUBY-2412     shared-1.1.pom has cyclic property declarationJRUBY-2413     org.jruby.util.io.NullChannel does not update Buffer positionJRUBY-2427     Add a --profile flag to JRuby that can run a simple Java-based instrumenting profiler.JRUBY-2428     Add a --debug flag that can enable JDB for anyone wanting command-line debugging capabilities. [Less]

Yesterday marked the first of the Ruby design meetings, where most of the Ruby implementers got together on IRC and started hashing out the solutions to several current concerns, and worked on getting more cooperation in the design of Ruby ... [More] features.This is slated to become a weekly meeting, and it's a huge deal. This will make the lives of all Ruby implementations much easier, and the meeting yesterday actually accomplished some very nice things.There were representatives from JRuby, Rubinius and macruby present, and of course also Matz, Koichi, Nobu and Tanaka from the Ruby core team.Some of the highlights was a decision to start working on a common API for MultiVM, initial acceptance to add the RubySpecs (coming from Rubinius originally) into the 1.8 and 1.9 build process, meaning that regression testing will be much better from now on, and also having most implementations using the same specs for compliance testing. In reality, this takes us one step closer to a real executable specification that everyone agrees on and has official blessing from Matz.In conjunction with this, a decision to set up continuous integration for 1.8 and 1.9 was made. The exact practicalities is still to be decided, but the decision to get it done is also very important.All in all, these are excellent news, and I'm feeling extremely hopeful about more cooperation between the Ruby implementors.If you're interested in exactly what happened, you can find the agenda, action items and log here: http://ruby-design.pbwiki.com/Design20080421. [Less]

In this post, Glen Stampoultzis posts a very interesting and clever sequence of steps by which he converts a piece of Java code into idiomatic Groovy code. I thought it was a nice article, so I'll do a very short spin on it: taking Glen's final ... [More] Groovy code and converting it into idiomatic Ruby.(I'll probably get my pants flamed off by you-know-who, but hey, it's a slow Thursday afternoon.)Glen's code, an algorithm for finding all n-length subsequences in a given array, ends up here:def subn(n, list) { if (n == 0) return [[]]; if (list.isEmpty()) return []; def remainder = list.subList(1, list.size()); return subn(n-1, remainder).collect() { [list.get(0)] it } subn(n, remainder);}(I had to make some edits because his code didn't appear to format right; I don't claim this code is 100% correct in this state.) Admittedly it's a very nice reduction from the original Java code. As Glen correctly surmises, it's largely due to those super-nice closures we get from Groovy. My first step is to make a few minor changes to make it run correctly in Ruby:def subn(n, list) return [[]] if (n == 0); return [] if (list.empty?()); remainder = list.slice(1, list.size()); return subn(n-1, remainder).collect() {|it| [list.at(0)] it } subn(n, remainder);endThe most notable changes here are flopping the statement-modifying conditionals on the first two returns and adding an "it" parameter to the collect block. Oh, there's also the "empty?" method. But largely it looks like pretty much the same code. The next obvious step is to remove things that aren't needed in Ruby.def subn(n, list) return [[]] if n == 0 return [] if list.empty? remainder = list.slice(1, list.size) return subn(n-1, remainder).collect {|it| [list.at(0)] it } subn(n, remainder)endMostly just removing some parens that are unnecessary (and distracting, for me) as well as line-terminating semicolons. Note that Groovy also can omit line-terminating semicolons. I think it's a matter of taste.def subn(n, list) return [[]] if n == 0 return [] if list.empty? remainder = list[1..-1] subn(n-1, remainder).collect {|it| [list[0]] it } subn(n, remainder)endNow we've eliminated the last "return" statement and made the list accesses use the array-referencing "[]" method...in the first case with a more idiomatic range of values rather than two parameters. Again, a matter of taste I suppose; two arguments works just fine. So that brings us mostly to the end of converting from the original Groovy code into Ruby. The new version is as readable as the original, but shorter by several characters. And of course this is my biased opinion, but it reads nicer too. I'm sure that will bring about all sorts of flaming in itself.At any rate, my point in this is certainly not to start a flame war about which version is better. My point is that the Groovy and Ruby versions are still largely the same. If you can learn to produce the Groovy end result, you can just as easily learn to produce the Ruby end result. So if you've stuck with Java because you're worried you can't learn Ruby, or you don't think Ruby is enough like Java...don't be scared! A whole Rubylicious world awaits you :)(Oh, and for you Rubyists out there...feel free to post your own improvements in the comments. I didn't want to change the original flow of the code, but I know it can be golfed down a lot more.) [Less]

And so, JtestR 0.2 has finally been released. The highlights include support for Expectations and TestNG, RSpec stories and lots of other goodies.Here is the release announcement:JtestR allows you to test your Java code with Ruby frameworks.Homepage: ... [More] http://jtestr.codehaus.orgDownload: http://dist.codehaus.org/jtestrJtestR 0.2 is the current release of the JtestR testing tool. JtestR integrates JRuby with several Ruby frameworks to allow painless testing of Java code, using RSpec, Test/Unit, Expectations, dust and Mocha.Features:- Integrates with Ant and Maven- Includes JRuby 1.1, Test/Unit, RSpec, Expectations, dust, Mocha and ActiveSupport- Customizes Mocha so that mocking of any Java class is possible- Background testing server for quick startup of tests- Automatically runs your JUnit and TestNG codebase as part of the buildGetting started: http://jtestr.codehaus.org/Getting StartedNew and fixed in this release:JTESTR-10 It should be possible to run TestNG testsJTESTR-12 Buildr supportJTESTR-13 CC.rb should be able to run JtestR testsJTESTR-17 Tests should be groupable and runnable per groupsJTESTR-21 Support RSpec storiesJTESTR-28 JtestR should include expectationsJTESTR-30 code coverage supportJTESTR-31 Autoloading of Java constantsJTESTR-32 Can't load IA 32-bit .so on a IA 32-bit platformJTESTR-33 JtestR should use latest version of JRubyJTESTR-34 Errors when project is in path with spaces on Windows XPJTESTR-37 Can't expect a specific Java exception correctlyJTESTR-38 Problem with mocking Java classesJTESTR-39 RSpec story runner seems to require rubygemsJTESTR-40 Package missing or.jruby.exceptions.RaiseExceptionJTESTR-43 It should be possible to get the generated mock class without instantiationJTESTR-44 New output files start with a whitespaceJTESTR-45 RSpec raise_error and Test/Unit assert_raise and assert_nothing_raised handled JRuby NativeException stuff correctly.Team:Ola Bini - [email protected] Abramovici - [email protected] [Less]

% history 1000 | awk '{a[$2] }END{for(i in a){print a[i] " " i}}' | sort -rn | head113 ls74 ~/workspace/jruby_trunk/bin/jruby59 cd48 svn28 ant18 jruby17 find14 rm14 pushd13 lsof

Today I spent some time connecting two languages that are finding themselves popular for solving wildly different kinds of problems. I decided I wanted to see how easy it was and if it was a workable solution if you would want to take advantage of ... [More] the strengths of both languages. The result is really up to you. My 15 minutes experiment is what I'll discuss here.If you'd like, you can see this as a practical example of the sticky part where two languages meet, in language-oriented programming.The languages under consideration is Ruby and Erlang. The prerequisite reading is this eminent article by my colleague Dennis Byrne: Integrating Java and Erlang.The only important part is in fact the mathserver.erl code, which you can see here:-module(mathserver).-export([start/0, add/2]).start() ->Pid = spawn(fun() -> loop() end),register(mathserver, Pid).loop() ->receive {From, {add, First, Second}} -> From ! {mathserver, First Second}, loop()end.add(First, Second) ->mathserver ! {self(), {add, First, Second}},receive {mathserver, Reply} -> Replyend.Follow Dennis' instructions to compile this code and start the server in an Erlang console, and then leave it there.Now, to use this service is really easy from Erlang. You can really just use the mathserver:add/2 operation directly or remotely. But doing it from another language, in this case Ruby is a little bit more complicated. I will make use of JRuby to solve the problem.So, the client file for using this code will look like this:require 'erlang'Erlang::client("clientnode", "cookie") do |client_node|server_node = Erlang::OtpPeer.new("[email protected]")connection = client_node.connect(server_node)connection.sendRPC("mathserver", "add", Erlang::list(Erlang::num(42), Erlang::num(1)))sum = connection.receiveRPCp sum.int_valueendOK, I confess. There is no erlang.rb yet, so I made one. It includes some very small things that make the interfacing with erlang a bit easier. But it's actually still quite straight forward what's going on. We're creating a named node with a specific cookie, connecting to the server node, and then using sendRPC and receiveRPC to do the actual operation. The missing code for the erlang.rb file should look something like this (I did the minimal amount here):require 'java'require '/opt/local/lib/erlang/lib/jinterface/priv/OtpErlang.jar'module Erlangimport com.ericsson.otp.erlang.OtpSelfimport com.ericsson.otp.erlang.OtpPeerimport com.ericsson.otp.erlang.OtpErlangLongimport com.ericsson.otp.erlang.OtpErlangObjectimport com.ericsson.otp.erlang.OtpErlangListimport com.ericsson.otp.erlang.OtpErlangTupleclass << selfdef tuple(*args) OtpErlangTuple.new(args.to_java(OtpErlangObject))enddef list(*args) OtpErlangList.new(args.to_java(OtpErlangObject))enddef client(name, cookie) yield OtpSelf.new(name, cookie)enddef num(value) OtpErlangLong.new(value)enddef server(name, cookie) server = OtpSelf.new(name, cookie) server.publish_port while true yield server, server.accept endendendendAs you can see, this is regular simple code to interface with a Java library. Note that you need to find where JInterface is located in your Erlang installation and point to that (and if you're on MacOS X, the JInterface that comes with ports doesn't work. Download and build a new one instead).There are many things I could have done to make the api MUCH easier to use. For example, I might add some methods to OtpErlangPid, so you could do something like:pid << [:call, :mathserver, :add, [1, 2]]where the left arrows sends a message after transforming the arguments.In fact, it would be exceedingly simple to make the JInterface API downright nice to use, getting the goodies of Erlang while retaining the Ruby language. And oh yeah, this could work on MRI too. There is an equivalent C library for interacting with Erlang, and there could either be a native extension for doing this, or you could just wire it up with DL.If you read the erlang.rb code carefully, you might have noticed that there are several methods not in use currently. Say, why are they there?Well, it just so happens that we don't actually have to use any Erlang code in this example at all. We could just use the Erlang runtime system as a large messaging bus (with fault tolerance and error handling and all that jazz of course). Which means we can create a server too:require 'erlang'Erlang::server("servernode", "cookie") do |server, connection| terms = connection.receive arguments = terms.element_at(1).element_at(3) first = arguments.element_at(0) second = arguments.element_at(1) sum = first.long_value second.long_value connection.send(connection.peer.node, Erlang::tuple(server.pid, Erlang::num(sum)))endThe way I created the server method, it will accept connections and invoke the block for every time it accepts a connection. This connection is yielded to the block together with the actual node object representing the server. The reason the terms are a little bit convoluted is because the sendRPC call actually adds some things that we can just ignore in this case. But if we wanted, we could check the first atoms and do different operations based on these.You can run the above code in server, and use the exact same math code if you want. For ease of testing, switch the name to servernode2 in both server and client, and then run them. You have just sent Erlang messages from Ruby to Ruby, passing along Java on the way.Getting different languages working together doesn't need to be hard at all. In fact, it can be downright easy to switch to another language for a few operations that doesn't suit the current language that well. Try it out. You might be surprised. [Less]