Eric West

esw9999@gmail.com https://github.com/edubkendo

I hold bachelors in both English and Philosophy, however, I have been studying programming full-time, independently, for the past year and a half. I will begin taking programming courses in the fall to round out my knowledge. I've been making open-source contributions almost since the very beginning. Most recently I've contributed to JRubyFX.

RSense, JRuby-Parser : Better Tooling for Rubyists

RSense (http://cx4a.org/software/rsense/) is an impressive software originally implemented by Tomohiro Matsuyama, billed as: "The most useful development tools for Ruby". It is a command-line backend, with Vim and Emacs front-ends to provide highly accurate type inspection, code-completion, and etc. The backend is easy to script, and it should be possible to write front-ends for any other editor with the capability to shell out. In fact, RedCarEditor did have a plugin for Ruby code-completion built around RSense. Sublime Text is an editor which could easily draw code completion, type inspection and other support from RSense via its plugin system.

Unfortunately, RSense has not been updated in some time. I think there are several possible reasons why the project may have stopped being worked on, and I will get to those in a minute. Although it still works well enough, there are multiple places where it still needs fleshed out. It parses Ruby code via a four year old copy of jruby.jar, and updating this would be the first step in an update or re-write of RSense. This is complicated by the fact that several years ago, much of the code RSense relies on for parsing and code introspection was moved out of JRuby and into a library called JRuby-Parser.

My primary goal for this project would be to port RSense to use JRuby-Parser. It appears that updates to RSense stopped somewhere around the time the split-up between JRuby and JRuby-Parser occured, so it is possible that the hassle of completing this port was part of what inhibited the development of RSense. However, having reviewed the code very thoroughly over the past several weeks, I believe the port to be fairly straightforward, despite the fact that it will mean touching almost all the code in the codebase.

Next, JRuby-Parser has added a great deal of functionality over time as code has been moved from the NetBeans Ruby plugin and into JRuby-Parser. Much of the code in the RSense codebase is duplicating functionality already present in JRuby-Parser. Secondary goals for the project would be to begin moving basic semantic/syntactic processing logic into JRuby-Parser, improving the JRuby-Parser API while simplifying RSense. If/when possible, explore rewriting sections of RSense in Ruby (It is primarily coded in Java), and beefing up JRuby-Parser's Ruby wrapper (eg. make the Visitor pattern more accessible from Ruby). I believe that Rubyists using RSense would be far more likely to contribute back, could they do so primarily in Ruby, so exploring this option would help guarantee RSense's continued development.

RSense can be a valuable tool with a fairly straightforward update, and has the potential to become an even better one.Quoting the RSense homepage: "In the future, the following features will be available: Static code checking, Caller jump, Refactoring". Further, the JRuby-Parser project should benefit from this project as I work with it and RSense.

My primary interest in RSense is to use it, ultimately, as the source of highly accurate, intelligent completions for a Sublime Text plugin. Currently, the only true intelligent auto-completion for Ruby in SublimeText comes from SublimeCodeIntel, a plugin that many people have a lot of difficulty getting to work, and that does not work at all with JRuby. I'm also highly interested in this promise of "Static code checking", and would love to see that come to fruition. Finally, I expect to learn a great deal about Ruby, Parsers, AST's, JRuby and programming in general. I am excited about exploring these topics.

[Timeline for implementation]

First Month : Begin porting code to use JRuby-Parser. Get it building, and functioning again. Aim to have it completing code at least as accurately as before, and passing all its tests, though this may take longer.

Second Month: If any failing tests remain, or there seems to be any reduction in usability, eliminate these problems. Otherwise, begin looking for places where functionality can be moved into JRuby-Parser, and/or code can be re-written in Ruby.

Thereafter: Ensure we have a polished, working version of RSense ready for release. Add tests for any new or improved functionality.

I've already begun the first part, laying the groundwork.

[Expected challenges, rough plan for coping with them]

The biggest challenge, for me, will be the Java language that both RSense and JRuby-Parser are written in. I've worked through a couple of Java books over the last year, but it is not the language I think most comfortably in. However, I am a very capable learner, willing to research and ask questions when necessary. I am also stubborn and will dig into a problem until I do understand it. I'd like to become much stronger with Java, and especially with using Java and JRuby together, as in this project, so I see this not as an obstacle but as an opportunity for growth.

Other challenges: One, the RSense codebase is almost entirely undocumented. There are a handful of FIXME and TODO comments, but otherwise there is almost nothing. I have already begun to overcome this by familiarizing myself with the codebase through extremely close reading of the code. Two: RSense uses a type annotation system to gain better insight into code that would otherwise be ambigious until it ran. The parser for these annotations is written with ANTLR, known for being complex, and entirely new to me. Fortunately, to complete the goals for this project, it shouldnt be necessary to change any of the code for the actual parser. I'd like to explore the possibility, at some point, of re-writing this parser with Ragel, but that would be unlikely to happen during the course of the project unless I've grossly over-estimated the difficulty of the project and ended up with far more extra time than I previously believed.