Tuesday, April 11, 2006

lab 61 - javascript tool

NAME

lab 61 javascript tool

NOTES

In this lab I wanted to get a standalone javascript interpreter for general scripting use within inferno.

[Deleted a section on reasons why I'd want to do this based on the mix of languages already available--it's not that interesting and is just me trying to rationalize why I like javascript]

There is already a javascript interpreter in inferno as part of the charon web browser. All I'd need to do is add a small set of host objects to interface with the OS.

In this lab I haven't included all the host objects I'd want; not even a fraction. This is just the setup, the beginnings of a javascript tool. The only host object I've added is System which contains three functions: getline, print, and readFile. Getline reads a line from stdin and returns it as a string. Print writes a string to stdout. ReadFile reads the in the contents of a file and returns it as a string.

Suggestions on what the host objects to add are welcome.

Here is an example script showing how to call the tool, called js.

% cat t1.js
function f(n) {
 return n * 2;
}

var s;
while((s = System.getline()))
 System.print(s + f(1));

% echo a | js -f t1.js
a
2% 

FILES

caerwyn.com/lab/61

4 comments:

demerzal said...

I think what would be interesting would be to embed the JS runtime within the HTTP server, and expose a set of host objects that allowed for one to interact, through Javascript, with the HTTP environment.

caerwyn said...

I agree! In fact I did this for work using Rhino embedded in a servlet so I could write javascript to glue together java libraries and generate web pages quickly while doing exploratory programming.

The same would be true with inferno's js if a nice interface existed to loadable modules like it does for rhino.

Darren Bane said...

If you're looking for host objects, take a look at "Object Reference" on the left-hand-side of JavaScript OSA. Bear in mind that a) its primary purpose is to emit AppleEvents to control other applications--these are the MacOS.AE* objects--and b) it uses the old MacOS terminology (e.g FileSpec) rather than the new BSD stuff (just a char * pathname), but you might be able to get something out of it.

Ricky Curtice said...

I know this is falling off the edge into ancient data, but I would think that if you were to start this again today you'd likely find the work of node.js to be of use at least as a reference for the objects to create...