## Calling Java Under Cygwin

While trying to set up Clojure under Cygwin I found that doing mixed-mode between Cygwin and Java isn’t very happy due to the ‘;’ vs ‘:’ in the classpath.

This post (via this post) provided an obfuscated Ruby program to take care of that for you… thanks!

#!/bin/ruby
# Slightly obfuscated cygwin + windows java wrapper, automate cygpath

cpi = ARGV.index("-cp") + 1
cp = ARGV[cpi] if cpi

XBCP = "-Xbootclasspath/a:"

xbcpi = ARGV.index{|i|i=~/^#{XBCP}.*/}
xbcp = ARGV[xbcpi] if xbcpi

if cp or xbcpi
def convert_paths(paths)
paths = paths.gsub(':', ';').split(';')
paths.map{|p|cygpath -aw #{p}.strip}.join ';'
end
ARGV[cpi] = convert_paths(cp) if cp
ARGV[xbcpi] = XBCP + convert_paths(xbcp.sub(XBCP, '')) if xbcp
end

java = '/cygdrive/c/Program Files/Java/jdk1.6.0_18/bin/java'
cmd = [java].concat ARGV

def e(s); "\"#{s.strip.gsub('"','\"')}\""; end

exec(cmd.map{|a|e a}.join(' '))


## Adding Soft Typing to Ruby

Here is an interview with two of the Diamondback Ruby developers. You can read more about how there system works in this paper: Static Type Inference for Ruby.

It is interesting that they took the approach to compromise by neither being too aggressive nor to permissive; in other words they wanted to make sure that people would actually use the tool. As such, type inference is strong enough to detect type errors, but permissive enough to allow for the same variable to have a different type of object assigned to it within the flow (dynamic extent) of a single method.

Another nice feature is the addition of a contract system for cases where type inference would not work; the two primary examples being utilization of the built-in classes which are implemented in C or the use of eval. The contracts specify the behavior and the implementation needs to conform to it.

With things like Diamondback Ruby, PLT Scheme Contracts, and Typed Scheme (mentioned in the paper) becoming available; I wonder if the statically vs lately typed language arguments will eventually go away.

(via LtU)

## Maglev Ruby

Ruby is often compared to Smalltalk; and I’m sure a bunch of folks have always wondered when someone would implement Ruby either on top of Smalltalk (or even in a similar manner to Smalltalk, aka Rubinius).

Avi Bryant wondered as such, and seems to have gotten a job out of it in producing Maglev Ruby (it is a video).

Maglev seems to be the combination of a Ruby VM implemented along with a distributed, concurrent object system to support the needs of Ruby on Rails.

I heard Avi speak at OSCON 06, and he seems to be a nice fellow; I’ll be interested to see how this pans out.

Strangely, I haven’t heard Maglev mentioned by anyone I know, perhaps Ruby VMs aren’t interesting.

## Emacs influence on Ruby

Who would’ve thought that Ruby’s block ‘end’ keyword was created to facilitate Emacs? Oh man!

When [Matz] was first starting out writing Ruby, he was coding the Emacs ruby-mode.el for it at the same time. He expressed some frustration with modes for other languages like Python and Pascal in which the editor could not look at a line of code and figure out where it should be indented to, so he resolved that Ruby as a language should not fall into that particular trap. With that in mind he chose the end keyword as a block delimiter so that it would be easier to write an Emacs mode for.