April 8th, 2008
Welcome Waxy.org and Slashdot readers. I blog about JavaScript, like it's my job, feel free to subscribe for a ton more posts like this.
Related Posts:
Note: I'm not the creator of HotRuby, as mentioned elsewhere - it is the work of a highly-skilled Japanese developer.
HotRuby is a project which aims to port the Ruby Virtual Machine over to ECMAScript (allowing it to run, directly, in a browser using JavaScript or indirectly using ActionScript in Flash).
Currently the code works by using Ruby 1.9's YARV (Yet Another Ruby VM) to compile down a Ruby script into opcodes, which are then serialized and passed to the browser for execution. It's a little bit indirect but it still capable of creating a compelling result.
If you were to run one of the examples in your browser the actual chain of execution would be something like this:
- Script finds <script type="text/ruby"></script> tags and extracts the inline Ruby code from them.
- The Ruby code is sent to the server via an XMLHttpRequest.
- The server-side CGI script (in Ruby, using Ruby 1.9) compiles the incoming Ruby into its associated opcodes and serializes it into a JSON data structure.
- The browser consumes the opcodes, translating it into JavaScript, and executes it.
To observe this full process we can take a look at the code in the provided benchmark and watch its full path through the server and final execution:
startTime = Time.new.to_f
sum = ""
50000.times{|e| sum += e.to_s}
endTime = Time.new.to_f
puts (endTime - startTime).to_s + ' sec'
For example, observe this portion of the CGI script:
#!
/usr/local/bin/ruby
# Requires Ruby
1.
9.
0
# The license of
this source
is "Ruby License"
require 'json'
require 'cgi'
cgi = CGI.new
puts "Content-type: text/plain\n\n"
puts VM::InstructionSequence.compile(cgi['src'], "src", 1, {}).to_a.to_json
and a sample of the opcode data returned by the server:
["YARVInstructionSequence\/SimpleDataFormat",1,1,1,{"arg_size":0,"local_size":4,"stack_max":3},"","src","top",["startTime","sum","endTime"],0,[["break",null,"label_21","label_29","label_29",0]],[2,["putnil"],["getconstant","Time"],["send","new",0,null,0,null],["send","to_f",0,null,0,null],["setlocal",4],4,["putstring",""],["setlocal",3],"label_21",5,["putobject",50000],["send","times",0,["YARVInstructionSequence\/SimpleDataFormat",1,1,1,{"arg_size":1,"local_size":1,"stack_max":2},"block in ","src","block",["e"],[1,[],0,0,-1,-1,3],[["redo",null,"label_0","label_22","label_0",0],["next",null,"label_0","label_22","label_22",0]],["label_0",5,["getdynamic",3,1],["getdynamic",1,0],["send","to_s",0,null,0,null],["send","+",1,null,0,null],["dup"],["setdynamic",3,1],"label_22",["leave"]]],0,null],"label_29",["pop"],7,["putnil"],["getconstant","Time"],["send","new",0,null,0,null],["send","to_f",0,null,0,null],["setlocal",2],9,["putnil"],8,["getlocal",2],["getlocal",4],["send","-",1,null,0,null],["send","to_s",0,null,0,null],["putstring"," sec"],9,["send","+",1,null,0,null],["send","puts",1,null,8,null],8,["leave"]]]
and you can find the full client-side virtual machine here: HotRuby.js.
Perhaps most fascinating about this, though, is the speeds that are able to be achieved with this script. Granted, the above benchmark is rather contrived, but the end performance results are quite fascinating:
| Firefox 3.0b5 |
2.47s |
| Firefox 2 |
6.71s |
| Ruby 1.8.2 |
12.25s |
We can see a 2.71x speed improvement from Firefox 2 to Firefox 3 and a 5x performance improvement over regular Ruby 1.8.2, running on the command-line.
It's a fascinating time to be working with JavaScript. The performance improvements that are being provided to us by the browser afford us a realm of possibility that wasn't, previously, viable. The fact that we're even discussing running a virtual machine, implemented in JavaScript, is quite impressive. I'm curious to see what applications end up being built with this implementation - and within what context they end up using it.
Tags: javascript, ecmascript, ruby, vm
37 Comments on 'Ruby VM in JavaScript'
August 8th, 2007
In the bustle of announcements surrounding OSCON, Blackhat, and the Ajax Experience one single, incredibly important, announcement was made: The introduction of two new Mozilla projects: IronMonkey and ScreamingMonkey.
The critical, core, component of this is the Tamarin virtual machine (which is an Open Sourced version of the ActionScript Virtual Machine that powered the Adobe Flash Player). Tamarin already supports ECMAScript 3 (and, thusly, JavaScript, ActionScript, and JScript) and parts of the upcoming ECMAScript 4 specification.
Briefly, since they're both still under planning, here's what IronMonkey and ScreamingMonkey are setting out to achieve.
IronMonkey is setting out with the goal of mapping Microsoft's Common Intermediate Language (CIL) to ActionScript Byte Code (ABC), allowing additional language implementations, such as IronPython and IronRuby, to run in the Tamarin Virtual Machine.
IronPython and IronRuby are implementations of Python and Ruby, respectively, that runs on .NET Common Language Runtime (CLR) (and, incidentally, also on Mono), written in C#.
IronRuby is built on top of the Dynamic Language Runtime (DLR)... DLR will ship as part of the Common Language Runtime (CLR) in the future...
To break all of this down: There are implementations of Python and Ruby that are capable of being compiled down to a Common Intermediate Language, which will then be able to be run on Tamarin via IronMonkey.
This is a huge, huge, deal. This means that JavaScript will no longer be the only viable scripting language in browsers that use that Tamarin engine. At the very least, there'll be two more languages to work with. However, if IronMonkey works out well, I wouldn't be surprised if we see an implementation of PHP that runs in the browser.
Tamarin being able to run JavaScript 2, Python, and Ruby really doesn't mean a whole lot (to the general web-developer public) if the languages don't work in all modern browsers (even though it'll give development on the Mozilla platform a considerable boost). This is where ScreamingMonkey comes into play.
ScreamingMonkey is the effort, being led by Mark Hammond, to allow the Tamarin engine to run within non-Mozilla browsers, starting with Internet Explorer.
Unfortunately, the Internet Explorer team is caught up fixing bugs in their existing ECMAScript implementation (JScript), thus their likelihood of implementing ECMAScript 4, in a reasonable time frame, is slim to none.
The result of this effort will be for a developer to be able to reference ECMAScript 4 or JavaScript 2 from a script tag and have it load a required plugin in order to execute it, for example:
<script type="application/ecmascript;version=4">...
</script>
or:
<script type="application/javascript;version=2">...
</script>
There's a detailed plan of attack laid out and it will require a lot of work. The end result still needs to be actualized, but it will most likely be in the form of a standalone Tamarin runtime (possibly embedded in another distribution) that will be able to hook into its relevant browsers.
As with IronMonkey, this is a huge announcement. This immediately helps to give credence to using the upcoming JavaScript 2 language as its cross-browser support is practically assured. While we're still a long ways off from being able to use this particular project, the result of it will surely be incredible.
Regardless of the outcome of either one of these projects, it's obvious that browser scripting is beginning to shift in some appreciable ways. Although, should these projects succeed the resulting effect upon the web development industry will be incalculable.
Tags: ruby, python, javascript, ecmascript, tamarin, .net, mozilla
18 Comments on 'The Browser Scripting Revolution'
December 16th, 2005
A fun online game that I've been playing, lately, is llor.nu (unroll, backwards). It's written using Ruby on Rails, has lots of nice Javscript/AJAXy things, and is Open Source.
The game, in and of itself, is rather simple - you roll the dice, collect money, pay rent, build buildings, and get more money. Which can be rather tedious - however, being a programmer, I saw an opprotunity to automate a bunch of the tedium and maximize my profits - and according to the discussion boards, I'm not alone. Recently, the game had an overhaul changing much of the dynamics, and much of my code. One of the things on the developer's 'to-do' list is to implement a public API, but until then, I've pulled together a number of commands (e.g. REST-like URL and parameter combos) that can get the job done. So, if you're interested in writing your own bot, it's definitely a good place to start.
Logging In
POST /login
user[login]=USERNAME&user[password]=PASSWORD
This is the essential first step of any bot - logging in to your account. The username and password are the ones that you signed up with originally.
Rolling The Dice
GET /js/take_turn/
The most simple of bots can do nothing but login and then roll the dice to kingdom come - under the current version of the game, it is very likely that you will become quite rich.
Buying A Building
GET /deeds/buy/NUM?levels=LEVELS
The next step, is to generate some form of perpetual income (from other hapless players, rolling their dice) - this can be done by buying an available plot and hoping that it'll be landed on. However, you must first know if you've landed on a plot that can be purchased - the easiest way to do this is to take the output from 'Rolling The Dice' and to check and see if it contains the text "buy and build". Some psuedo code:
login();
while( 1 ) {
data = GET('http://llor.nu/js/take_turn/');
if ( data.contains( 'buy and build' ) ) {
GET('http://llor.nu/deeds/buy/2?levels=1');
}
}
The next important step is to determine what type of building and how many levels to buy - There are four types of buildings numbered 2 (lowest worth), 3, 4, 5 (highest) - and multiple levels (1 to 30ish). You'll probably want to focus on buying on particular type of building, exclusively - it'll make your code, and management, much simpler.
That should be sufficient to get you started hacking around - just make sure that you don't call their poor server too frequently - leave a couple second delay it, to be nice. (Otherwise there may not be any more game to mess with.) If there's interest, I'll be happy to delve into the following:
- Using ducks, Figuring out when to use a duck
- Using hard hats, Figuring out when to use a hard hat
- Figuring out how much money you have
- Renaming Buildings
- Upgrading Buildings
- and Selling Buildings
At the very least, be sure to check out the game, it's very slick, to say the least (and look for me up on the high score board!).
Update: The 'can I buy' text has been changed to 'buy and build' (to work with today's update).
Tags: programming, api, rails, rubyonrails, games, ruby
13 Comments on 'Playing With llor.nu'
