IronJS 0.2 is out
IronJS 0.2
IronJS is an ECMAScript 3.0 implementation built on top of the Dynamic Language Runtime from Microsoft which allows you to embed a javascript runtime into your .NET applications.
Thanks to
- John Gietzen for all his work on ECMA3 conformance whom without this would not have been possible
- Christian Knutsson for the awesome logo
Changelog
- ECMA3 Conformance
- Added 5,500 ECMA3 conformance tests with over 30,000 assertions
- Major API refactoring moving all Module/Functions located in Api.fs to their appropiate classes in Core.fs instead
- Re-implemented the AST analyzer to make it single pass
- Re-implemented variable handling allowing for faster and easier compilation
- Removed the dependancy of Microsoft.Dynamic.dll for CLR4 projects
- Removed dependancy on FSKit
- Implemented the Date object
- Implemented the RegExp object
- Implemented missing functionality on String.prototype (match, split, search, replace)
- Implemented F# operators ? and ?
- Implemented F# operators for all common binary DLR expressions
- Implemented a Sputnik test suite runner, courtesy of John Gietzen
- Implemented a proper REPL console, available in the aptly named “REPL” project.
- Implemented dynamic invoke operators for calling IronJS functions with an unknown amount of arguments
- Implemented a new F# based lexer and parser which allows IronJS to drop the dependencies on Xebic.ES3.dll and Antlr.Runtime.dll
- Cleaned up and removed a lot of old/redundant code
- Renamed ObjectClass to “Schema” and split out the dynamic functionallity into it’s own DynamicSchema class
- Replaced the FunctionCompiler class with an F# function with the signature IronJS.FunctionObject -> System.Type -> #Delegate
- A lot of smaller improvements to code stability and readability
- Added debug constructs in big parts of the codebase that only gets compiled when the DEBUG flag is set
- Refactored several constructors in the IronJS.Ast.Tree union to be more obvious
- Unified error handling, so it all passes through IronJS.Error and its members
Binary
Source
Information
- IronJS Blog
- IRC: #ironjs @ irc.freenode.net
- Twitter: @ironjs
IronJS Blog 
Hi, does it support CoffeeScript in this release?
Demis J Bellot
April 19, 2011 at 10:16 pm
There is no native CoffeScript parser yet, there’s plans for one but currently you’ll have to use an external (or javascript-based) CS compiler to run CS on IronJS
Fredrik Holmström
April 19, 2011 at 10:32 pm
yeah so can you use the javascript coffeescript parser to compile and run *.coffee files? I heard the earlier had probs doing this?
BTW it’s a good attribute to be able to run CS since it’s a mark of good ECMA compliance.
Demis J Bellot
April 19, 2011 at 10:38 pm
Yes, you should be able to do that. We’re conforming to about 98.2% of the spec currently, if you run into any troubles just submit a github issue and we’ll get right on it.
Fredrik Holmström
April 19, 2011 at 10:42 pm
[…] the release of IronJS 0.2, the code below is the result of a 30-minute play I had this morning, which shows how easy it is to […]
First steps with IronJS 0.2 « Duncan Smart's Weblog
April 20, 2011 at 12:40 pm
Is there a binary for the Silverlight runtime?
Scott Rudy
April 22, 2011 at 4:49 pm
Currently no, but it’s planned for 0.2.1
Fredrik Holmström
April 24, 2011 at 12:04 pm
There’s one other JavaScript in .NET project which you could test against, that’s here…
http://javascriptdotnet.codeplex.com/
That one implements Google’s v8 engine. Doesn’t mean it’s anywhere near as complete or fast as v8, but it would be interesting to see a comparison with that.
Uriah
May 2, 2011 at 10:19 am
It would be interesting to compare to the JavaScript.Net interfaces to v8, as it would be comparing the PInvoke vs. internal .Net code… I think that v8 would probably win out overall, but would depend on the cross-bounds interaction.
I’d still like to see E4X and node compatibility… there’s always spidernode for that though. It would just be interesting as a next step to expose the node api structure to ironjs. (that and e4x support would be particularly nice for interacting with other legacy systems, or services).
tracker1
June 3, 2011 at 10:10 pm
I unfortunately had to stop using IronJS for Jint, because Jint supports VS2008 well, and was a lot more user friendly. Eg, had a lot more documentation/examples.
I found it really hard trying to read F#, though I didn’t try much. I’m hoping that it will come out with better documentation, and that implementation will be easier in C#. Though, maybe when I finally migrate to VS2010, it will be better in that.
We’ll see. I’ll keep an eye on this, but at the moment, I’m using Jint.
Uriah
June 4, 2011 at 10:09 am
The main problem with V8 is that it’s not thread safe at all, which means you can only have one running “script” per process at any time. And since the Windows “philosophy” is 1 process /w N threads, compared to the unix N proccesses /w 1 thread each. And process management in windows is sub-par I found it personally very hard to use V8 for anything through .NET
Not saying that V8 is a bad JS engine, it’s top-3 fastest and a lot more advanced then IronJS!
Fredrik Holmström
June 5, 2011 at 11:13 am
Yeah definitely. I am not particularly interested in that project, as it doesn’t seem to be as developed or supported compared to IronJS and Jint. However, I just meant you should add it to your list of projects to compare to. Always good to see a % support, and speed comparison between all the different projects of this kind. Shows us also, that you’re interested in making this the leading solution, by keeping an eye on your competitors/etc.
Good to see work on this. I’m keeping an eye IronJS, and looking forward to the next release.
Uriah
June 5, 2011 at 11:45 am
@Uriah: Could you specify exactly what problems you had running IronJS under VS2008? We have DLLs compiled for .NET 3.5/CLR2 that should work under VS2008.
We’ll gladly try to fix any problems you were having, but if you don’t report them on the issue tracker (http://github.com/fholm/IronJS/issues) we have no way of knowing what they are or how to track and fix them.
Regards,
Fredrik
Fredrik Holmström
June 5, 2011 at 11:11 am
Yeah, I should have. I was using the VS2008 binaries, but I had trouble (vaguely from memory) setting parameters, functions, and executing the script. Unfortunately I didn’t have much time, and so I was looking for something simple and functional. In this regards, I found implementing Jint to be extremely easy, where as IronJS I found a little confusing. I think it might have been due to the way each of you handle the setup and execution, partially due to IronJS compiling the JS with Jint just interpreting it? Or something like that.
I can’t remember exactly what problems I had, but I will re-try IronJS at some stage, and post any problems I have then. Is there a forum for this help? Besides the issue tracker? (As maybe my problems are likely due to me not understanding it, as opposed to it being a bug)
More documentation and examples, particularly in C# is a huge must though.
Uriah
June 5, 2011 at 11:38 am
Did you use any P/Invoke in IronJS?
If not, why there is no “Any CPU” assemblies?
Nana's lich
June 13, 2011 at 3:37 pm
There is no use of P/Invoke, but the struct that is used requires a specific layout for each architecture.
Fredrik Holmström
June 14, 2011 at 9:18 pm
You could compile the x64 assembly as AnyCPU which would run on both x64 and x32, but it’d waste 4 bytes running on 32bit architectures (since we need account for that a pointer possibly could be 8 bytes (x64) as we don’t know which architecture we’ll be running on).
Fredrik Holmström
June 14, 2011 at 9:52 pm
How much wasted memory would that amount to in practice? Have you done any profiling on this on any large JavaScript corpus to see whether it has any practical meaning?
asbjornu
June 30, 2011 at 10:15 am
Does that mean there are some problems we can’t solve with IntPtr? Then we can’t use IntPtr instead?
Anyway, great job!
Nana's Lich
July 5, 2011 at 8:50 am
I can now understand why.
But you’ve already fixed it^^ great!
Nana's Lich
July 8, 2011 at 2:56 am
How come this isn’t on nuget (http://nuget.org/) as yet?
David Fowler
June 15, 2011 at 5:15 pm
It is now!
Fredrik Holmström
June 30, 2011 at 3:03 pm
Hi Fredrik,
I want to integrate IronJS into my open source project. But I found there is no LanguageContext defined in IronJS.
In my code, I use the below code to get script engine:
var scriptEngine = scriptRuntime.GetEngineByFileExtension(Path.GetExtension(filePath));
It requires language setup configuration in app.config like the code below:
But the class “IronJS.Runtime.JSContext” is not defined in IronJS, so the statement “m_ScriptRuntime = ScriptRuntime.CreateFromConfiguration();” always throw exception.
So my questions are:
Is there a LanguageContext implementation in IronJS?
If yes, where is it?
If no, do you have a plan to implement it?
Could you answer my questions?
Kerry
July 15, 2011 at 3:19 am
Hi Kerry!
There currently is no LanguageContext available for IronJS, nor any other of the “scripting language hosting” classes/interfaces you can implement to hook into LanguageContext, ScriptRuntime, etc.
The plan is to some day implement this, but we’ve found that *most* people that use IronJS just create an instance of it’s runtime directly through something like: var x = new IronJS.Hosting.CSharp.Context();
Regards,
Fredrik
Fredrik Holmström
July 15, 2011 at 6:56 am
Thanks for your reply!
My project is an application framework, and it is designed to support any iron languages.
So I won’t know which Iron languages the users of this project will use.
I want to ensure that, after user put any Iron language script files(*.py, *.js) into the command folder, these script can work correctly without any code changes of the application framework.
So the LanguageContext feature of IronJS is required by me and others who have similar requirements.
Please think about this feature!
Thanks, Kerry Jiang
Kerry
July 15, 2011 at 8:06 am
I want to the LanguageContext feature of IronJS, too.
This is *must* feature for me.
Where can I vote the request to implement LanguageContext feature?
jsakamoto (@jsakamoto)
October 20, 2011 at 2:18 pm
How to parse JSON(send as string parameter) to a method in JavaScript function
Hi,
I am new to IronJS and facing difficulty parsing JSON in JavaScript method.
My C# Code
string jsonString = “{\”Name\”: \”Ankur\”, \”Sex\”: \”Male\”}”;
var o = new IronJS.Hosting.CSharp.Context();
o.ExecuteFile(@”C:\CustomScript.js”);
var handleJson = o.Globals.GetT(“HandleJson”);
var result = handleJson.Call(o.Globals, jsonString).Unbox();
Console.WriteLine(result);
JavaScript method in CustomScript.js
function HandleJson(jsonStr) {
obj = JSON.parse(jsonStr);
return obj.Name;
}
Everytime I do this, I get error message saying “ReferenceError: JSON is not defined”
Guess, “JSON.parse” method is native to browser and isn’t available server side.
I can use jQuery method obj = $.parseJSON(jsonStr); as well but don’t know how to load jQuery file at server.
Any thoughts on what I am doing wrong or how to fix it?
Thanks.
Ankur Nigam
November 1, 2012 at 1:53 pm
I have found the fix to it.
JSON.parse is an unknown JS method at Server(which is why we were getting the error)… So, we need to add/load “json2.js” before CustomScript.js file and then we will be good.
json2.js can be downloaded from following location: https://github.com/douglascrockford/JSON-js
Following is the updated C# code.
string jsonString = “{\”Name\”: \”Ankur\”, \”Sex\”: \”Male\”}”;
var o = new IronJS.Hosting.CSharp.Context();
o.ExecuteFile(@”C:\json2.js”);
o.ExecuteFile(@”C:\CustomScript.js”);
var handleJson = o.Globals.GetT(“HandleJson”);
var result = handleJson.Call(o.Globals, jsonString).Unbox();
Console.WriteLine(result);
No changes are required in CustomScript.js
Cheers!
Ankur Nigam
November 1, 2012 at 5:26 pm