Managed JScript

Dec 10, 2008 at 8:32 PM
I doubt this is the correct place to bring this up, but I didn't know where else to do so...

I was wondering what the distribution policy and licensing is for the Managed JScript implementation on top of the DLR. I would like to use the DLR to provide scripting capabilities in my application and would like to support Managed JScript, IronPython and IronRuby as choices for scripting (and other languages as they come out as well). I know where to get a distribution of IronPython and IronRuby, but I don't know where I can get a Managed JScript redistributable, or if anything like this exists.

Thanks for any information you may have.

slide
Coordinator
Dec 10, 2008 at 9:01 PM

The Dynamic Language Runtime (DLR) and its hosting APIs are the direction we're moving for .NET app scripting.  As you seem to know, today you can use IronPython (v2 due today) and alphas of IronRuby.  All this code is open source (source and binaries at http://www.codeplex.com/IronPython and http://rubyforge.org/projects/ironruby).  We're currently working out the details and product planning around which languages we should provide as officially supported scripting languages for .NET app scripting.  Customer input is very valuable at a time like this.  From your question, it sounds like you'd be interested in all DLR langs, not just JScript support.  Is this the one scripting language that you want for your users or are you interested in other languages?  If only JScript, what motivates your interest in JScript?

Thanks,

Bill

From: slide_o_mix [mailto:notifications@codeplex.com]
Sent: Wednesday, December 10, 2008 12:33 PM
To: Dynamic Language Runtime
Subject: Managed JScript [dlr:41990]

From: slide_o_mix

I doubt this is the correct place to bring this up, but I didn't know where else to do so...

I was wondering what the distribution policy and licensing is for the Managed JScript implementation on top of the DLR. I would like to use the DLR to provide scripting capabilities in my application and would like to support Managed JScript, IronPython and IronRuby as choices for scripting (and other languages as they come out as well). I know where to get a distribution of IronPython and IronRuby, but I don't know where I can get a Managed JScript redistributable, or if anything like this exists.

Thanks for any information you may have.

slide

Read the full discussion online.

To add a post to this discussion, reply to this email (dlr@discussions.codeplex.com)

To start a new discussion for this project, email dlr@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Dec 10, 2008 at 9:47 PM
On Wed, Dec 10, 2008 at 2:01 PM, [email removed] wrote:
> From: billchi
>
> The Dynamic Language Runtime (DLR) and its hosting APIs are the direction
> we're moving for .NET app scripting. As you seem to know, today you can use
> IronPython (v2 due today) and alphas of IronRuby. All this code is open
> source (source and binaries at http://www.codeplex.com/IronPython and
> http://rubyforge.org/projects/ironruby). We're currently working out the
> details and product planning around which languages we should provide as
> officially supported scripting languages for .NET app scripting. Customer
> input is very valuable at a time like this. From your question, it sounds
> like you'd be interested in all DLR langs, not just JScript support. Is
> this the one scripting language that you want for your users or are you
> interested in other languages? If only JScript, what motivates your
> interest in JScript?
>
> Thanks,
>
> Bill
>


The reason I am currently interested in JScript is mainly for a
migration path. I currently have a scripting engine based on the old
JScript.NET code provider stuff and use that for scripting my
application. I would like to move to the DLR so that other languages
are supported, and because it is the future direction of application
scripting on the .NET platform. The Managed JScript would provide me a
much smaller porting path for current scripts, as well as
incorporating the ability to use IronPython and IronRuby for new
scripts.

Thanks!

slide
Dec 11, 2008 at 10:06 AM
Almost the same situation here. We've got a solution still based on the CLR 1.1 and using the VSA to provide extensible scripting capabilities to the users (this is the most important part of our product actually). Altrough our product supports any VSA supported language, the most and the only used is JScript.NET now.

We are planning to move to latest technologies in the near time (like clr 2.0, .net 3.5 etc) and I thought of DLR as a better replacement to the VSA. Ruby/Python/ToyScript ;) / etc. support is nice, but we need the easiest migration path for our customers, and from this perspective we certainly need Managed JScript support for CLR 2.0 based DLR.

I've heard much about "Managed JScript != JScript.NET", but since it will be based on the ECMA Script 3.0 and integrated with CLR and due to specifics of our application, I hope that migration of the existing customers "scripts codebase" won't be very hard.

Nik Medved, TopSoft Australia.
Coordinator
Dec 11, 2008 at 6:40 PM

[BCC’ing internal list ...]

Hi, Nik.  Thanks for the note and background on your needs.  Yes, I get pinged a lot about a DLR-based (Manged) JS.  You raise a few issues, so I’ve added a couple of folks for their awareness and possible follow up.  As I said in my last post, we’re currently figuring out our plans about the suite of languages to offer and in what form (binary only like VB and C#, fully open sources do what you want, shared source, or just free with .NET, and so on).  Part of our planning is resources and timelines since JS is not the only language we get asked about as you might suspect :-).

Your other comments though should be addressed by the VSA team.  While it is great that you are looking at the DLR for language choice and as a scripting solution.  You should note that out of the box, we only provide execution and hosting APIs for languages.  VSA and its brethren products offer a lot richer support for hosting such as project models, macro recording, in-proc and out-of-proc execution, full dev IDE experience, etc.  Anyway, I’ll let them speak to their JScript.NET migration strategy.

Cheers,

Bill

From: brainsucker [mailto:notifications@codeplex.com]
Sent: Thursday, December 11, 2008 2:07 AM
To: Dynamic Language Runtime
Subject: Re: Managed JScript [dlr:41990]

From: brainsucker

Almost the same situation here. We've got a solution still based on the CLR 1.1 and using the VSA to provide extensible scripting capabilities to the users (this is the most important part of our product actually). Altrough our product supports any VSA supported language, the most and the only used is JScript.NET now.

We are planning to move to latest technologies in the near time (like clr 2.0, .net 3.5 etc) and I thought of DLR as a better replacement to the VSA. Ruby/Python/ToyScript ;) / etc. support is nice, but we need the easiest migration path for our customers, and from this perspective we certainly need Managed JScript support for CLR 2.0 based DLR.

I've heard much about "Managed JScript != JScript.NET", but since it will be based on the ECMA Script 3.0 and integrated with CLR and due to specifics of our application, I hope that migration of the existing customers "scripts codebase" won't be very hard.

Nik Medved, TopSoft Australia.

Read the full discussion online.

To add a post to this discussion, reply to this email (dlr@discussions.codeplex.com)

To start a new discussion for this project, email dlr@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Dec 16, 2008 at 6:13 PM
A source distribution of managed jscript would be wonderful: a boon to those wanting to offer scriptability in their applications.
Jan 6, 2009 at 11:12 PM
Not to beat a dead horse :-) but has there been any progress on a new release of Managed JScript to go with the latest IronPython and DLR releases? I would like to use IronPython 2, but I don't believe that the MJS released in the ASP.NET futures will work with the DLR release that IP2 uses.

Thanks!

slide
Coordinator
Jan 7, 2009 at 4:14 PM

Hey, slide.  I’m sorry, but there’s been no progress on firm plans around DLR JScript.  We release it in binary form that works with IPy 2.0 via our codeplex.com/sdksdk.  It only works in Silverlight, and those bits have been aging on the vine since last summer.  I’m sorry, but due to resource shuffling, I suspect it will be a while before we circle back to our JScript with getting IPy up to 3.0 compliance, finishing up IRuby v1, and shipping core parts of the DLR in CLR 4.0.  We know a JScript is high on the request list, which is why we’re trying to figure out what we can do there.

Thanks,

Bill

From: slide_o_mix [mailto:notifications@codeplex.com]
Sent: Tuesday, January 06, 2009 3:13 PM
To: Bill Chiles
Subject: Re: Managed JScript [dlr:41990]

From: slide_o_mix

Not to beat a dead horse :-) but has there been any progress on a new release of Managed JScript to go with the latest IronPython and DLR releases? I would like to use IronPython 2, but I don't believe that the MJS released in the ASP.NET futures will work with the DLR release that IP2 uses.

Thanks!

slide

Read the full discussion online.

To add a post to this discussion, reply to this email (dlr@discussions.codeplex.com)

To start a new discussion for this project, email dlr@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Jan 20, 2009 at 1:36 PM
Hi world !

I am working on an application that have same needs : entry points for scripting in javascript or vb. I am trying to use managed Vsa libs, but there are lacks of features and no place I have found to talk about it.

DLR seems good, but I don't know if it can replace Vsa libs.

I need at least same hosting behavior, but with more features, like when engine needs to retreive the object that I published into the runtime (VsaEngine.Items.Create() ), I need to know wich code item requires it. For example, a Form with 2 TextBox (2 scripting entry points) in the first, you add all the main code, in the second, all your functions, and global objects defined in one can be access in the other, but with a way to tell from wich code item it was looked up (through IVsaSite.GetGlobalInstance).

If someone knows wich lib I can use, please let me know...

Thanks.

Damien.
Coordinator
Jan 21, 2009 at 1:13 AM
Hi, Damien.  Our email has been down to codeplex today, so I've tried sending you a private note with contact with whom you can follow up.

Thanks,
bill
Jan 25, 2009 at 3:36 AM
I'd just like to chime in on how much I'm looking forward to Managed JScript, yet how disapointed I am that it seems to be languishing in the backwoods of the DLR. I appreciate that it's now usable in Silverlight, but if I watned to develop with javascript in the browser, I'd use javascript in the browser. When the DLR was started it appeared that IronPython and Managed JScript would be the first releases. IronPython has lived up to all the hype and then some. But Managed JScript seems to be left behind.

I'm excited for Managed JScript because JavaScript is a surprisingly great language but it doesn't currently have a set of  viable desktop libraries. .Net with javascript would open a tremendous set of doors to do everything from systems administration to Office plugins, to WPF apps that I couldn't even imagine.

I should point out that I would much rather get a surprise 0.9 beta Managed JScript source release in a half a year from now than a 0.2 alpha completly open source release that is thrown out to the community just waiting to die on the vine. And if you have to make it closed, well, we'll cross that bridge when we come to it.
Jan 25, 2009 at 3:02 PM
Thought I'd add my two cents to this thread...

First, I agree 100% that Javascript is a surprisingly great language (this from a C# guy with C++/comp.sci. roots). And I think its the perfect DLR target... critical mass of existing devs combined with interesting features that make it useful far beyond its traditional "web scripting" role. In fact, its exactly this value proposition that led me to implement a Javascript variant on the 0.9 DLR for my company's product.

I'm not at liberty to share this code publicly... but there's nothing stopping you from doing it yourself. In fact, its easier than you probably realize... not trivial, but certainly not impossible.

1. You'll need a Javascript parser... as an ANTLR guy, I'll suggest you look here for a big head-start... http://research.xebic.com/es3/

2. Once you've got C# versions of the parser running, you'll then need to map ANTLR trees to your own custom object model... see www.antlr.org for various examples of this (you might also consider buying Terence Parr's excellent ANTLR book)

3. From here you'll need to build up the DLR infrastructure for your language implementation... you can borrow from the ToyScript implementation to help you, though it's often dated and (by design) overly simplistic

All told it took me less than 10 days of effort to get "happy path" expression and statement evaluation working... robust error handling and other production-ready elements will take longer, but we've budgeted for that.  :-)

So, I guess this might not be the answer to everyone's prayers, but I would recommend building a DLR Javascript implementation yourself! You'll learn a ton about languages and the DLR, and you can add whatever features you want.

Shoot me an email if you have other questions about how to get started... jplane@gmail.com

Josh

Jan 28, 2009 at 7:54 PM
I had some success using the Managed JScript assemblies from the ASP.NET Futures July 2007 release, but have yet to try with the stuff in the Silverlight dynamic languages SDK. If one were to use the IronPython and Managed JScript with the Microsoft.Scripting assemblies in that release, you _should_ be able to get something going.
Apr 15, 2009 at 5:42 PM
Edited Apr 16, 2009 at 11:38 PM

To add another voice, about 7 years ago I went out on a limb and replaced a proprietary algol-68-like script language with an ActiveScript host and JScript, then mechanically ported (to ECMAScript/jscript) some 680 scripts that our server-side, non-web-based product used at the time.  After 3 months of intense 80 hour weeks, 20,000 lines of code, and a mechanical cross-compiler later, this gave us almost 2 orders of magnitude performance improvement, plus source level debugging and a wealth of other (hard to implement) features like RegEx and COM support.

Today, we have over 16,000 scripts dependent on this technology and it is core to our product.  The team recently wrote well over 7,000 lines of JScript, plus about the same in unit tests, to implement a significant new feature.  Call us crazy (well, call me crazy), but it worked out pretty well given our existing design and deadlines, except that small objects take too much memory plus the garbage collector sucks, hurting performance during results processing; I had to resort to on-demand serialization of some inner objects to/from JSON, plus smart caching of deserialized objects, to reduce the memory profile and squeeze out better performance... but I digress.

We could stand to improve our runtime performance and script load time (it takes over 2 minutes to load and cache all those scripts).  The weekly script-bundle download is huge.  In addition, I'm getting a lot of pressure to un-Microsoft-ize our core engine to reduce COGS by eliminating Server 2003.  I have given some consideration to Linux and Rhino, but we use a lot of Win32 API's and some WMI in our core object model and would need to extend SAMBA to get all we need.  The core helper libraries can run on JScript.NET, with a minor port to eliminate namespace conflicts, but the hosting APIs are all deprecated and the scripts themselves are an unknown.  I'm afraid to implement my own ECMAScript compiler because we have used (ok, I have used) damn near all ECMAScript features, including closures, functions as first class objects, significant extensions to built-ins, evil eval (for JSON), etc.

IMHO Managed JScript on the DLR would help on these fronts (though I doubt compilation would reduce the script bundle size).  The biggest resistances to all this are the size of the .NET installer runtime, which we would need to redistribute on our installation media (3.5 is over 220MB!), and adding yet another dependence on a proprietary Microsoft technology locking us in to an expensive OS.

Please help.

-- James

 

Apr 15, 2009 at 10:26 PM
It would be nice if MS would even release the source under the MS-PL so it could become a community project. HINT HINT :-)

slide
Apr 21, 2009 at 3:53 PM
Edited Apr 23, 2009 at 5:34 AM
I said,
"IMHO Managed JScript on the DLR would help on these fronts (though I doubt compilation would reduce the script bundle size). The biggest resistances to all this are the size of the .NET installer runtime, which we would need to redistribute on our installation media (3.5 is over 220MB!), and adding yet another dependence on a proprietary Microsoft technology locking us in to an expensive OS."
Didn't mean to leave this on an anti-Microsoft note.  If JScript.NET on the DLR gives us a clear competitive advantage (performance, features, reduced maintenance, etc.), then I think I can sell this solution.  As to the installer, a smaller server-style runtime (without, for example, any UI-related code) would be quite helpful, but is not a serious roadblock.  As to OS, Embedded Server 2008 might fit the bill for reduced COGS and is something worth investigating.