Project Description
DLRScript is a SilverLight 2.0 sample using the DLR. It lets you use DLR-based languages in the Script tag of a normal HTML (or .aspx, or .jsp or .php, etc.) page.

 DLRScript News Feed 
Wednesday, September 10, 2008  |  From DLRScript

I just wanted to point out to the world that my Open Source DLRScript (built on top of Silverlight 2 Beta2) compiles JavaScript (and it uses the familiar Script tag).

The major difference is I am one guy (doing too much sidework that my personal projects are suffering) versus the huge Google regime. I’m also not as far as long from a compatibility perspective that I would like to be.

The big thing that DLRScript proves though is that Silverlight can be used to create a consistent/performant Script runtime for the browser... in fact the best thing with DLRScript is that you can swap out JavaScript and use something else... like Ruby! (or Python).

Once I’m done tech reviewing John Papa’s book I need to devote some more quality time to this...

Thursday, July 24, 2008  |  From DLRScript

It took a bit of time for this release. In the end I had to take everything a step back (as well as there are probably a few "mid thoughts" in here as the release of SL2 Beta 2 caught me a bit by surprise.

The step back is that we no longer get script code lines when there are issues. I’ll try to bring this feature back, but right now if it breaks, you’ll know it.

Future direction
I need some feedback on this. I’ve been thinking about scrapping any attempt at jscript compatibility and am thinking more about ecma3 support (DLRJScript has an ecma3 mode). The benefit there is that I could start focusing on building a better set of client-side APIs instead of a more compatible one. That said, I’m not sure how qualified I am at coming up with a "better" set of client-side APIs.

I do want some feedback though. Let me know what you think:

Friday, May 02, 2008  |  From DLRScript

[I really should stay out of these discussions... I really should, but I can’t resist.]

The other day I saw an article on Composition over Inheritance (I forget where I saw it). The article did a good job of explaining what "composition" is. This is my simplistic understanding (which means that someone will probably come in and tell me I have it ALL wrong... what else is new?): "composition" means essentially wrapping objects instead of direct inheritance (so instead of inheriting from X you instead have a private instance of X in your class that you use, but you create your own interface possibly something that looks totally different from the "wrapped" class).

I only really have one concern in all this; at least with what I have read (and not necessarily the last article I read on this subject). The advice almost comes across as "thou shalt avoid inheritance (if you can)." The implication is that inheritance is something bad. Now I understand that inheritance can complicate things in a unit testing scenario (be it TDD or POUT).

The problem is that implication that inheritance is bad. I think it might be better to discuss some things I recently did in the DLRScript source code. I recently used composition to build a compatible XMLHttpRequest object in my DLRScript environment (no, it’s in the unreleased bits which will be released as soon as I can test it properly... I was hoping for a JQuery compatibility, but it looks like that ain’t happening this iteration). I wrapped the SilverLight HttpWebRequest object. This let me create a Mozilla/Safari-compatible XmlHttpRequest object that has no extra features other than what those objects contain.

That said I also have some code I have had in place for some time that also works well. This code inherits from the SilverLight HtmlDocument, and creates a document object that is more in line with what we are used to seeing in client script in the browser. I also have a class that wraps HtmlElement to create an object that is also more familiar to JavaScript junkies. I recently added a style property to each of these elements, for instance. My style property simply utilizes the setStyle/getStyle methods (I forget the actual method names) which is already available in the HtmlElement (for instance) to get/set values of individual style properties. In this case having a few dangling methods doesn’t really hurt because I already need 90% of what is already there. I do have to override a few methods since I need to emit DomElements (my inherited form of the HtmlElement) from getElementById instead of an HtmlElement.

My point is this. Think. Think! THINK!!! THINK!! Don’t just blindly follow a rule. Look at your code. Take control of it. Make it do what you want it to do. Make sure that it makes sense. and if someone else is going to be using it, ask someone else if they think what you are doing makes sense. And then DOCUMENT IT!! At least provide an example of how to use it.

Thursday, April 24, 2008  |  From DLRScript

I have begun working on DLRJScript-JavaScript compatibility. I was actually successful running my first externally created JavaScript -- EcmaUnit 0.4 (which is a small JS testing framework). I did have to make a couple modifications.

I’m becoming aware of the size of this job though. I’m currently porting a Mozilla-compatible XmlHttpRequest object which I think will work with all the major Ajax frameworks. I’m not sure which Ajax Framework I’ll actually target as the first on to run. I could stick with the man and make it work with the MS Ajax client library, I could go with Prototype that so many people swear by or I could use something else (JQuery is looking rather interesting to me in this regard). The biggest thing I require though is either an extensive sample project or a test suite itself. This makes it easier to see if my JavaScript replacement is working OK or not. Once I have a reasonable compatibility (one or more frameworks working fairly good with minimal issues) then I’ll move over to making the various languages capable of communicating with one another (so I can loadup JQuery and then use it, clientside, from Iron Ruby).

In case you forget why you might want to do this, it’s simple really; DLRJscript is faster (because it’s compiled) then traditional JavaScript (which is interpreted).

Monday, April 14, 2008  |  From DLRScript

As you may or may not have seen, over the weekend I released a new version of my DLRScript project.  It’s coming along. It adds 3 things: File loading via the src attribute, better exception reporting for DLRJScript(it shows you what line of script code failed), and improved DLRJScript performance.

File Loading
I could probably write a bunch on this (and probably should in another article). Basically I am dynamically loading content (script files) from the server. I also extended HTML a bit in that you can now use the same script tag to load a script from the server and to write additional code that will load after the script has loaded. It looks like this:

   1: <script type="DLRJScript" src="/somefile-on-the-server.js">
   2:     function doSomething()
   3:     {
   4:         // Code found here
   5:     }

JS Performance

Because of the new way I am creating the JScript engine, I get JScript code to compile, so the code that executes is faster than standard interpreted Client-Side JavaScript. I did a simple test which is within my project over on CodePlex. The test simply adds 15 <hr /> elements to a hidden div. It records the time before and after the routine. First run in the DLRJScript results in about the same speed as standard client=side JavaScript. The second run results takes about 1/2 the time and the third trip is even faster (the 4th-6th attempt takes about the same amount of time as the 3rd run, so I figure that’s as fast as it gets). I’m not sure if this implies that the DLR optimizes code even more after subsequent runs of code or not (I know the .NET spec supposedly will optimize code after it has been run a few times).

Anyway, my test is not scientific in case you are wonder. There could be additional processes on my box that may make the results vary. Everything is a very crude approximation. I did run the client-side version several times to see as well with about the same results.

The Future

Ok, my plan is to get my DLRJScript to be more compatible with standard client-side JavaScript using DOM2. Right now I know I’m not even at DOM1 spec. I will be testing various libraries to see if I can get them to run with my implementation. It may result in a faster way to run JavaScript in the browser. Also, since the code is really running within the SilverLight plugin, the script code should be standardized and run the same in every browser (well, at least in theory).

Tuesday, March 18, 2008  |  From DLRScript

In the next week or so I will be releasing a new version of my DLRScript. It will have external file sourcing/loading via the src attribute (I have that working right now). I would release it today except for 1 issue.

what is in the file is this


jsapi.alert("Hi JScript here");


jsapi.alert("Hi Python here")


$jsapi.alert("Hi, I'm Ruby and YOU are NOT!")

Here's the issue. I think I discovered a bug (in my code). When you try to launch multiple alert boxes you get 1 of them and errors for the rest. Which makes sense to me (as you the user need to click the button on one of the Alerts. I will correct this.

I also discovered another subtle little issue that I want to account for.  The problem is that since we are moving code Asynchronously there are multiple threads involved.  My current development executes code as it gets code back, but it should execute this stuff in the order it appears on the page (I'll be correcting that one too)

Probably the next week or so, and then I'll be moving forward on my other ideas (most notably the Object Model).

Ruby DOM??

While I'm on the subject of Object Models, I had some discussions with some friends to see if I should duplicate client-JavaScript's DOM model or if I should create something else.

The wisdom from both seemed to be that duplicating client-JS' DOM for JScript and Python would be good, but you Ruby guys would something that is Rubyish (no, not rubish... I said Rubyish).  I was wondering if I might get a Ruby programmer to help me understand what that means (cause neither of my friends can answer that question).

So here is the question.  If you had the ability to write Ruby code as a client language (and you can with DLRScript) what would the framework look like? 

Tuesday, March 04, 2008  |  From DLRScript

I skipped blogging about the last release mainly because I have been busy trying to find work (as well as preparing for a training I'm doing this month).  Anyway, I thought I should put out a little update, so my readers know that I have made a new release.

New Language!

If you've seen the download page you will notice that I have a new language, and no, it's not the language I wanted to add.  It's not Ruby.  I figured out how to get DLR JScript (and I'm calling it that so as to not confuse it with JavaScript the client-side code -- which exposes some objects to DLRScript)

Object Cleanup

With the last release I cleaned up a little code, and renamed the DomHelper object to jsapi.  I'm still not 100% thrilled with that name, but for now it works.  Basically this object exposes certain DOM functionalities to DLRScript languages as well as exposes a couple JavaScript (client-side) functions/features like alert, confirm, prompt, and eval (although the latter still seems to be working a little strangely).  I will be adding setTimeout/clearTimeout once I have the time.  They are there, but not very usable (or useful).  You can probably use setTimeout, but won't be able to stop it, and only against client-side (non-DLR) JavaScript functions. At some point I'll make it possible to hook up your DLRScript language's functions to setTimeout/clearTimeout

I also felt like I should respect the camel-case of aspect of JavaScript, so I switched the functions to camel-case (first character is lowercase then the first char of each "word" is uppercase).

Additional Object abstraction

I normally wouldn't do this, but I needed to do this so I could begin to introduce a few streamlined properties.  Here's the objects:

  • HtmlObject

    • HtmlDocument
    • HtmlElement

You can probably guess that HtmlObject is a parent to the other two (and you would be correct).  One of the things I introduced was a cross-browser "text" property for all objects returned from a getElementById (or the document object).

This also let me enable a number of pieces of functionality you would fully expect (stuff like attaching/detaching events, adding/removing new elements/attributes, reading/setting properties/tag attribute/styles, etc.

I will eventually start beefing this up so that you don't have to resort to using the function to read a property (or to read a style)

What's next?

Well, I really, really, really(!!) want to get IronRuby working.  I'm hoping that after Mix08 that should be a little easier to do.  Once I do that then I think I'll do a little bit of work on the object model, and will start looking at adding things like communications support.  I also NEED to get the script tags to load DLR scripts from the web server (and more importantly cache them!)

I also want to test inter-language communication... maybe Python is better at a task then say Ruby (not sure, so don't be shooting me over the comment), but you want to create more of a DSL (which Ruby is stellar at)... You could potentially write some functions in Python and use them from Ruby.

So basically I have my work cut out for me... Oh yeah, the DLRScript Project is here. It comes with a couple sample files for you.

Tuesday, February 26, 2008  |  From DLRScript

[You know I hate making announcements... It seems like my expectations are always higher than what actually happens.  I've announced stuff before that I thought was somewhat impressive -- maybe not though-- with like zero interest]

This weekend I created a new project over at CodePlex called "DLRScript."  I put this ominous description - "DLRScript is a SilverLight 2.0 sample using the DLR. It is based on the DLRConsole found in the sample in the SilverLight 2.0 SDK, but with a new advanced twist (check back here for more info later... I want to be the first to do this which is why I'm mum on the subject) "


So let me tell you the background.  I recently was pondering the new upcoming beta of SilverLight 2.0 (something I have been waiting impatiently for a year).  I started thinking about some of my past demos and playing around with it.  You see I have been using it to get rid of JavaScript altogether and replace JS with C#.  I contemplated creating a project for that functionality a few months back, but with SilverLight 2.0 so far away it didn't seem like a great idea at the time.  I also have begun recently playing with some of the DLR languages.  I have to say that I really like Python (I wish I was better with it), and Ruby is very intriguing to me as well.

I started thinking about how with SilverLight 2.0 we could actually add new languages that could be put into a script tag.  So I built it..

A picture is worth 1,000 words

Here's whit it looks like-

   1: <script type="DLRPython">

   2: def clickHandler():

   3:         DomHelper.alert("Hello from Python")        

   4: eh = DomHelper.createEventHandler("clickHandler")

   5: document.GetElementByID("clickMe").AttachEvent("onclick", eh)


If you look closely I have a custom object called DomHelper.  The reason that exists is that I am currently having problems adding namespaces (but I can easily add variables to the script environment).  DomHelper knows how to do a couple things. Send Alerts, and Create An Event Handler from a method name (there are others, but I need to work on them). 

That "document" variable is not the standard DOM document, but a reference to the SilverLight environment's HtmlPage.Document.  Right now I am having problems with setting the property values of DOM Element (I will be fixing that soon).

Why did you do this (JavaScript is fine)?

I'll blame George Tsiokos again (he was the one who told me he didn't want to have to extensively know JavaScript).  I personally don't like that we web developers need to be fluent in a bunch of things : HTML, Language on the Server (be it C#, PHP, python, or Ruby), CSS, and JavaScript.  I know that the markup stuff is fairly simple for most of us... it's having to be fluent in 2 languages is what stinks.  So my goal is for a Ruby on the Rails developer to be able to use Ruby both client-side and server-side.

Some caveats (it's an alpha what do you want?)

  • You need to have the SilverLight 1.1 Alpha Refresh (from September) installed.
  • The project is a VS2008 project so you'll need that and the VS2008 Tools for Silverlight alpha (I think this came out in December)
  • I have exactly 1 DLR language working: Python. 
  • I will try to get Ruby working shortly. 
  • I have code in place for DLRJScript, but it doesn't work (I'm getting an initialization error). 
  • I don't have the files to try VBx.
  • Everything will change after Mix and the release of the beta (unless someone from MS wants to give me a pre-release <wink />)
  • The code is a mess right now, so consideer it a rough prototype (that works)

Future Plans

  • Get ALL existing DLR Languages working (the one I haven't mentioned yet is IronScheme... are there others?)
  • Improve the support for all the basic JavaScript environment functions (prompt, setTimeout, clearTimeout and eval would be nice to actually have working)
  • Be able to fully traverse the DOM (this may be working... I just may need to figure out how to get it working... a gold star to anyone who figures it out before me)
  • Be able to load modules from the file system (setting a the source attribute for a DLR Language)
  • Come up with a sane way to compress a python (or other language) script (maybe there already is a way that I don't know about).  Python appears to be a little more chatty (and being able to minimize the download)

The project will be available to download shortly...

 DLRScript News Feed 

Last edited Apr 12, 2008 at 3:12 PM by DevTheo, version 4