Clearing the air about Silverlight and the DLR
07. May, 2007 
27 Comments
It’s been interesting looking at the reactions from around the blogosphere. With so many people playing telephone, I thought I’d collect a bunch of facts together in one place so that folks can get a clearer picture about what we’re doing.
-
The DLR requires the CLR. So this means that it only works with the Silverlight 1.1 Alpha that was released at MIX, and not the Silverlight 1.0 Beta.
-
The source code for DLR, IronPython (and IronRuby when it is released) are being released under the Ms-PL. The Ms-PL is a BSD-style license.
-
The DLR will also run on top of the desktop CLR V2.0, not just the Silverlight CLR. We have a generic hosting API that lets us retarget the DLR to run on top of arbitrary hosts. Silverlight is only one such host.
-
The Silverlight 1.1 Alpha bits released at MIX include the DLR, IronPython and managed JScript.
-
Silverlight lets you run compiled .NET code in the browser, not just Python and JScript code. Any assembly that has been compiled to target the Silverlight libraries should just work. So if you want to write code in C#, VB.NET or Boo to target Silverlight, knock yourself out.
-
Our JScript implementation targets the ECMAScript 3.0 specification.
-
We will implement four languages for the DLR: IronPython, IronRuby, JScript, and Visual Basic. As of this writing we are only releasing the source code for IronPython and IronRuby under the Ms-PL. We have not decided whether we will release the source code for either JScript or Visual Basic.
-
Silverlight is targeted at browsers that run on the two most popular client operating systems: Windows and Mac OS X. Miguel de Icaza was quoted as saying that they will release a Mono+Linux implementation of Silverlight by the end of the year.
-
Silverlight V1.1 will only target Intel Mac OS X machines.
Is there anything else that I missed?
“The DLR will also run on top of the desktop CLR V2.0, not just the Silverlight CLR.”
Hi John,
So does this mean that the Silverlight CLR is different than the Desktop CLR? There are two distinct CLR’s?
If you write an assembly using the desktop CLR, say one containing strictly business logic and that used the namespaces that are available in the Silverlight CLR, could you re-use it in your Silverlight application after a re-compile? Would you even have to recompile?
Confirmed: Silverlight 1.1 will only support Intel OS X machines
You’ve been kicked (a good thing) – Trackback from DotNetKicks.com
Could you please send a mail to the navision team at microsoft and recommend them that they should port the C/AL language to the .net platforum using the dlr. (without c#-generator-behind-the-scenes-.net-black-magic comming in the new 5.1 version)
you have so many more languages at microsoft. whats with axapta?
@Scott:
There are differences between desktop and CoreCLR. For example P/Invoke and COM interop code isn’t present in CoreCLR because it doesn’t make sense for the browser security model.
Does the CLR used in Silverlight for OS X share the same codebase as the Windows version (ie: with some #ifdef’s or similar included) or is mono used?
CoreCLR shares the codebase with Windows. There is no Mono code in Silverlight.
John LamによるSilverlightとDLRのまとめ
John Lam on Software: Clearing the air about Silverlight and the DLR IronRubyプロジェクトの中の人のJohn LamがSliverlightとDLRについてまとめていますので、ちょっ
John LamによるSilverlightとDLRのまとめ
John Lam on Software: Clearing the air about Silverlight and the DLR IronRubyプロジェクトの中の人のJohn LamがSliverlightとDLRについてまとめていますので
You said:
Silverlight V1.1 will only target Intel Mac OS X machines.
The 1.1 alpha is running just fine on my PowerBook. Still, I’m upgrading to a MacBook Pro later this week, so the point is moot, at least for me.
Can’t wait to get my hands on Silverlight with IronRuby. Are you attending RailsConf next week by any chance? I am. Email me if you’re attending and we can chat IronRuby. I’ll buy you some beers.
BTW, just thought I’d mention, I’ve been a Rails developer for over a year, using Mac OS X & Textmate. Silverlight might just make me a Windows and MS Visual Studio customer again.
But if and only if, Ruby and Python are fully supported in the next release or through fully supported VS add-ins.
If Ruby and Python are never fully supported by Visual Studio, whether as native features or through officially supported add-ins, I’ll just use Textmate to create my XAML and Ruby script for Silverlight client-side, and Textmate for the Rails back-end.
I’m not switching to that POS of an app server, IIS, or the other POS, ASP.Net, that’s for sure.
Hi John
definitely looking forward to a first IronRuby release (even beta-ish).
I have one specific question: are there any plans to support interaction with existing libraries or gems, or will IronRuby support only pure ruby + dotnet libraries ?
best regards and hope you enjoy the new job (you seem to!)
Thibaut
Just wonder …
Recently Microsoft announced that it drops future development of Visual FoxPro package. Taking into acount that VFP is a “dynamic” language from the “begining”, I wonder why VFP development was dropped.
Was it only a “marketing move” or were there any technical reasons (with DLR support) behind it ?
So I would like to ask if DLR is capable enough to build something like VFP on top of it …
@Thibaut:
We are going to port a set of ‘core’ C-based Ruby libraries to C#. As for what ‘core’ is, we’re still figuring that out. This is similar to what we’ve already done using IronPython.
@gotenks:
I’m pretty sure we’ve never had any discussions with the VFP team. And Microsoft is a *big* company, so I have no idea what those guys are up to – wherever they are!
Since I know nothing at all about VFP, I can’t comment on the feasibility of implementing it on top of the DLR. That said, perhaps the real value of VFP is from its runtime environment + design-time environment vs. just the language?
Congratulations on a great presentation!
I saw this Python code in the source code for DLRConsole.
SetIntValue = DependencyObject.SetValue.Template[int]
What would be the JavaScript equivalent?
Cheers,
Eddy
There is currently no support for generics in the Alpha release of JS for 1.1. But it’s on the roadmap …
Thanks for the reply, John. I guess I’ll stick with IronPython for now
Where is the documentation for generics in IronPython? I haven’t found any
Eddy
Silverlight and the Dynamic Language Runtime
I was talking to my new teammate, the honorable Dr. Andrew Sithers (not sure if he honorable or not,
Silverlight and the Dynamic Language Runtime
I was talking to my new teammate, the honorable Dr. Andrew Sithers (not sure if he honorable or not,
Is it possible to run the Silverlight CLR without a browser?
We have a big problem with the desktop CLRs because only one version can run in one process. I understand the Silverlight CLR does not have this restriction. However, we would also need COM Interop support.
Is there any solution for this problem?
Regards,
Michael
@Michael:
We’re thinking about this, but we don’t have any definite plans for running Silverlight CLR outside of the browser at this time.
I am invested in Silverlight. Please consider making it run on the PPC Mac (17mil 2001-2005) and making it run H.264.
Does IronPython run Django smoothly?
John, how to know which classes are available in the desktop CLR versus Silverlight, or rather which classes are not available in Silverlight ? Any reference you could point me to ? Cheers
It seems the problem with using Boo to generate Silverlight content is that Boo apps require (at least) Boo.Lang.dll as some sort of runtime, and this is compiled against the desktop CLR.
http://bit.ly/8PCfAA
Boo compiled SL apps will still run, but only on a host environment where the desktop CLR is present (at least that is the inference).
@JonathanP:
You should just have to recompile Boo against the Silverlight assemblies in the SDK … (the nice thing about Open Source!)
@John
Thanks for that tip, but isn’t recompiling Boo successfully against the SL assemblies dependent on the fact that Boo does not use any APIs that are unique only to desktop CLR?
(If my understanding above is correct, then I guess the next question would be, how likely is it that Boo’s usage of APIs happens to coincide with the subset found in CoreCLR?)
@JonathanP:
I can’t speak to whether they do or not. In the core language, it’s less likely. For libraries though, that’s a different story. We had to do work in IronRuby and IronPython to create a platform adaption layer to redirect I/O appropriately. It would be worht reaching out to the Boo folks to see if this is something that’s on their list of things to do …
“In the core language, it’s less likely. For libraries though, that’s a different story” I see. Well, unlike Python and Ruby, Boo doesn’t really have its own library as it was written from the ground up to be a .Net language and thus depends on the .Net Framework exclusively (afaik). So that may be reason for optimism.
The two SVG attachments in http://bit.ly/8PCfAA show the different dependency graphs of System.Windows.dll (part of SL, afaik) and Boo.Lang.dll (which needs to be included with all Boo-compiled SL apps). In particular, [Ss]ystem.dll takes different paths to mscorlib.dll. Also, if you look at these dlls using a text-based dependency checker, the mscorlib.dlls they reference have different tokens (one clearly being that of CoreCLR and the other for desktop CLR).