Ruby bindings for a server-side javascript engine? - javascript

I'd like my rack application to be able to interface with a server-side javascript engine.
As of now the only way i know this could be possible, is by running JRuby and Rhino on the JVM, but I'm hoping for a leaner solution.
Has anyone heard of another, more rubyish perhaps, option ?
Edit : Reading the comments I'm starting to think I've been mistaken assumig that having both JRuby and Rhino run on the JVM would imply some interoperability between ruby and javascript...?
That's not a desirable solution for me anyhow, but still i'd like to clear that up.

The Ruby Racer is now out of pre-alpha and is hovering somewhere between alpha and beta. It now supports:
calling ruby code from javascript
calling javascript functions from ruby
embedding ruby objects into the javascript scope.
letting ruby objects be your javascript scope

Johnson is a RubyGem that turns the Mozilla SpiderMonkey JavaScript engine into an MRI C extension and allows very deep integration between Ruby and JavaScript,
there is a fork of Johnson which replaces the SpiderMonkey engine with the Mozilla TraceMonkey engine and
Lyndon is like Johnson but with JavaScriptCore instead of SpiderMonkey and MacRuby instead of MRI.
I think I also remember someone working on embedding V8 with MRI, but I can't find the reference right now.
The main problem with Johnson is that MRI is an incredibly crappy language implementation that leaks memory left and right, and the only language implementation in the world that could possibly be even more crappy is SpiderMonkey. Thus, the TODO list in the Johnson Git repository doesn't exactly inspire confidence; it only contains one item, and I quote literally:
Stop freaking segfaulting.
Lyndon is built on a much better foundation, but it obviously requires running OSX on the server. Plus, MacRuby hasn't been released yet.
I think JRuby+Rhino is probably the most stable option, although you will have to build the integration yourself: they are just two independent language implementations that happen to live on the same VM, but there is no integration between them.
A different take on the problem is RKelly which is a JavaScript parser and execution engine written in Ruby.
As an alternative you could try to approach the problem from a different direction: instead of keeping your application logic in JavaScript and running that both on the client and the server, you could keep your application logic in Ruby and run that on the server and the client: there are a couple of compilers out there that can compile (a subset of) Ruby to JavaScript. On of them is RubyJS. (There is also HotRuby, which is a YARV bytecode interpreter written in JavaScript, but that would very likely be tremendous overkill for what you are doing.)
And last but not least you could do what Rails originally did with their JavaScript helpers: you neither define your logic in Ruby nor JavaScript, instead you define it once in an internal Ruby DSL and generate both the Ruby and JavaScript logic from that.

Have a look at The Ruby Rhino. It uses jruby and rhino to embed javascript into your ruby environment. Among other things, it supports safe evaluation, calling ruby functions from javascript and vice-versa(javascript functions from ruby)
There is also "The Ruby Racer" which embeds v8 into MRI. This is still very much pre-alpha phase, but I hope to have a useable version sometime in march of next year
Another engine I know of is Snarl which also uses jruby and rhino to a similar effect.

Related

Creating a simpler, domain-specific language by restricting the Javascript support in Google's V8?

Is it possible to create a simpler language by restricting the Javascript support in Google's V8? I'd like to embed the V8 engine in my own tool to run dynamic scripts, and like the idea of V8 precomiling the source for speed. However I need to drastically restrict what is possible within the language.
That means no dynamic allocation of data containers (e.g. arrays), no imported libraries, no recursion, no threads. It's more similar in philosophy to Renderman Shading Language than a general purpose language. The 'new' language is thus much simpler, and I'm only considering JS due to familiar syntax and the fact there's a good 'compiler' already (V8). I might also want it to run script code from within Chrome's native code (NaCl) environment, which Google seems to be working to support in V8.
How easy is it to redefine the JS 'grammar', or whatever other code define the language?
My other option is to create a new compiled language from scratch (maybe using LLVM stuff).
For all the features restriction you want, you would need to carry out a major surgery on V8 as V8 is never designed for such a radical modification.
An alternative solution is to invent a JavaScript-like language (with all the limitations you can impose) and compile it into normal JavaScript which then you can run with V8 (or any other JavaScript engine, for that matter). Well-known examples of such an approach are GWT (from Java), Dart, and TypeScript.
Take a closer look at squirrel language :
http://squirrel-lang.org
from description overview :
"both compiler and virtual machine fit together in about 7k lines of C++ code and add only around 100kb-150kb the executable size."
Enjoy!

Is there a JavaScript (ECMAScript) implementation written in Python?

Are there any JavaScript (ECMAScript) implementations written in pure Python? It is okay even if its implementation is very slow.
Doesn't seem to be under active development anymore but you could check out pynarcissus, http://code.google.com/p/pynarcissus/source/browse/trunk/jsparser.py
Seems like a binding to V8 (JavaScript interpreter in Google Chromium) is available also, http://www.advogato.org/article/985.html
There is one, of an unknown level of completeness, written in RPython (a subset of Python, that is to say, it runs as normal Python): https://bitbucket.org/pypy/lang-js/overview
You may want to take a look at pydermonkey or python-spidermonkey, both of which, I believe, are python implementations of the Mozilla javascript interpreter.
I would recommend that you just stick to node.js on your local development box, translate your CoffeeScript files over to JavaScript, and deploy the translated scripts with your apps.
I get that you want to avoid having node.js on your servers, that's all fair and good. Jumping through hoops with Python invoking JavaScript to translate CoffeeScript seems more hassle to me than it's worth.
I created Jispy to embed JS in Python.
From the docs:
A JavaScript Interpreter In Python
Jispy is an interpreter for a strict subset of JavaScript, fondly called LittleJ (LJ). It employs recursive descent for parsing and is very easily extendable.
Built for embedding JavaScript
Jispy's original vision was to seamlessly allow embedding JavaScript programs in Python projects. By default, it doesn't expose the host's file system or any other sensitive element. Some checks on infinite looping and infinite recursion are provided to tackle possibly malicious code.
It comes with an interactive console, so you can get up and running in no time.
Hope this helps.
Have you heard of PyV8? It's a Python wrapper of Google's V8 JavaScript engine. It may be what you're looking for.

Practicality of compiling another language to Javascript?

Recently several tools have been released such as pyjamas and Scheme2js that allow one to take code in a language such as Python or Scheme and compile it to Javascript.
But how practical is such a tool?
I could see debugging being quite painful as you would have to debug the compiled javascript code itself, and correlate any bugs in that code with the corresponding lines in the original python/scheme/etc source code. Even with an intelligent stack trace such as the pyjamas -d option provides, this still seems tedious.
Also, libraries such as jQuery make writing Javascript much more fun and productive. But for many developers Javascript is still a new language to learn.
Has anyone worked with compiled Javascript in a production environment? Any recommendations or comments on the practicality of compiling to Javascript instead of writing your code directly in Javascript?
I believe GWT, based on Java, may be the most popular product of this kind, though I wouldn't describing it as "compiling Java to JS" but rather as "generating JS code". While I personally share some of your doubts, and would rather code JS directly, I have to admit that it is indeed an extremely practical as well as popular tool, entirely production-ready: I observe that, internally, many web apps that are rich and complex enough to warrant a front-end / back-end split are more and more often ending up as a Python back-end and a Java front-end -- the latter specifically to allow GWT (of course there are also plenty of Python front-ends, and plenty of Python back-ends, but I think this is a trend).
Google Wave uses GWT and is probably the most talked-about web app using it so far; together with the huge number of GWT-using web apps listed here, I think it establishes beyond any doubt that the approach is practical (as well as popular;-). Whether it's optimal (vs. writing actual javascript with a good framework in support) is a harder question to answer.
One of the more heavily used JavaScript compilers is GWT. This compiles Java to JavaScript, and is definitely used in production. The web interface to Google Wave is written in this system.
Also, Skydeck wrote Ocamljs, in order to make it easy for them to write FireFox extensions. That also worked quite well.
In summary, if you can write a good compiler, there is no showstoppers keeping you from writing a good JavaScript compiler.
Google Web Toolkit does it (Java to Javascript compiling), and GWT is used widely by Google (duh) and many others, so it definitely is practical.
Since the code is autogenerated, you debug problems in Java - assumption that the problem is in your code, and not in the compiler code, is true in 99% of all cases.
List of languages that compile to JS
As an another example Haxe could be mentioned. Haxe is a independent language and compiles to Flash 6-10, JavaScript, NekoVM and also to c++ - source code. Why is this practical?
you could use features the language itself could not offer
recompile code on multiple platforms (e.g.: form check in JavaScript and on server side)
there is a remoting package for communication between the platforms, and its genius.
autocompletion through the compiler
compile time type checks
If you are interested, you could start reading here.

Which ingame scripting language should I support?

The ingame script will control NPC/AI logic.
If I were to implement ingame scripting feature which language should it support?
JavaScript (builtin browser support)
TCL (interpreter in java)
Lua (popular)
Squirrel
CSI
Other
Keep in mind my implementation will run on multiple platforms like .net, flash, javascript and java.
What are the pro's and con's of the listed possibilities? How long will it take to implement the interpreter?
What features are ingame scripters looking for?
What are other games implementing?
I am thinking to vote for javascript due to the fact that everybody can read and write it.
What are your thoughts?
I'd use Lua, because it's terribly easy to embed. Embedding Python appeared to be complicated and I haven't really pursued that.
This link may be of further use if you want to know more about embedding Lua and its advantages/disadvantages.
Use Lua. It is a beautiful language, widely adopted in game industry.
There are Lua bindings for most of your platforms:
.Net: LuaInterface
Flash: Lua Alchemy
Java: Kahlua (alternative implementation)
There is also llvm-lua project, which may be helpful for porting Lua to other platforms.
As for JavaScript as a host platform... This subject recurrently appears in the Lua mailing list, but no serious solution were published yet. If you really need to host Lua in JS, please ask in the Lua mailing list, perhaps some people could share their experience on the subject.
I would prefer Python for its bindings in many languages.
I think you mean "integrate" the interpreter, and not "implement" it. Depending on your skills, creating an interpreter for a scripting language could take a lot of time.
I know for sure that Python and Lua have bindings for .NET and Java -- you can embed the interpreters. Don't know whether there are any bindings for Javascript and Flash.
The problem with Python is that there are three variants all made by different people.
IronPython for .NET
Jython for Java
and the regular CPython
I haven't worked on Jython so I won't comment about it. But there are certain portability issues between IronPython and CPython. For example: IronPython doesn't support native C extensions. If there are scripts written in CPython which use these, you will have a hard time porting them to IronPython. Also, if the IronPython scripts use any .NET libraries, you will have a hard time porting them to CPython.
Implementations of Lua, on the other hand, come from a single place and I don't expect such problems.
That depends on how complex your code will be (how complicated the behavior of NPCs can become). Tcl, Lua and JavaScript are for simple tasks. Writing large pieces of code in these languages quickly tends to become unmaintainable (especially for casual users).
Squirrel uses a C-like syntax which most people will be comfortable with but how about tooling support? If you have to write everything with Notepad, that will severely limit you, too.
Python is a mature language that is easy to learn (just compare the Lua "tutorial" to the one which comes with Python). While the various Python versions might seem intimidating (see Rohit's answer), the Python code in your game will be the same for all of them. It comes with an IDE (IDLE) and there are other IDEs which support Python which gives you code completion, debugging, running test cases, etc.
If you want to use Python consider using Stackless as it is rather better at threading than stock CPython. It's used in some MMORPGs (EVE Online, IIRC) so it's got some track record in games. Plus, it is very good for continuations (part of the reason it was developed in the first place), which is quite a good model for 'simulation' type logic that one use in games.

How to turn the V8 compiled javascript into an EXE?

I know that google's v8 compiles javascript into native machine (binary if I understand correctly) code.
Is there a way to take the output and turn it into a exe?
I don't think you can directly turn a piece of JavaScript into an executable using V8, but you can probably make an application that bundles the V8 engine with the JavaScript and runs it as a stand-alone.
You can find all information about V8 on its project page.
Also note that JavaScript can't be completely compiled as it's a dynamic language. With V8, it's JIT-compiled (like .NET, for example.) It's still possible to turn it into a stand-alone executable though (like .NET, for example.)
If you want to develop stand-alone applications that make use of HTML for rendering, you could have a look at Adobe Air as well.
Javascript cannot be compiled just once. The language has eval which is pretty widely used. (for JSON for instance) You need to carry around the JIT, and the whole runtime.
JIT here is only an optimization, not the way to get rid of the compiler/interpreter.
Node.js embeds V8. This might be a good example to learn from.
There have been a few tries at making js into native code, it's not something that can be used in production by any means, more of an academic interest.
The Rhino interpreter for java has an option to make js into (java) bytecode so one approach is to convert to bytecode and then from bytecode to native with GCJ. There is some discussion about Rhino and GCJ but I don't know if anyone ever tried exactly that. https://groups.google.com/forum/#!msg/netscape.public.mozilla.jseng/c3tqyLZ19fw/8V4HeuMtIXUJ
Another approach is using Python, specifically Py-Py which itself is written in a non-standard subset of Python called rPython. rPython is not meant for human consumption but it has the benefit of being something which can be compiled to native. One interesting (albeit wacky) experiment was to compile Javascript to Python and then in some cases that Python happens to be valid as rPython and can be compiled down to native with the rPython compiler.
http://mozakai.blogspot.com/2010/07/experiments-with-static-javascript-as.html
If a .exe file is really important, I would bundle V8 with your app since even if you can compile js to native, you still need a full interpreter if you use any eval() or similar. It would not be hard to write a tool for bundling everything into an .exe file as long as your users don't mind either an 8MB exe or 8MB V8.dll file.
As a last thought, Big G has started allowing "native" apps based on chrome (google: "chrome packaged apps"). They have low level system access and can use the WebKit renderer allowing you to create your GUI in CSS and HTML and they have their own windows and icons so it is not obvious that they are running inside of chrome. This is probably still premature but it's something to keep an eye on in the desktop applications field.

Categories