Hybrid App Debugging Aside - The DLR Hosting API

In my series on Hybrid App Debugging, I showed the following code for executing a Python file in a hybrid C#/IronPython app.

The DLR Hosting API has three distinct levels of functionality. As simple as this is, technically it’s level 2 since it’s using a ScriptEngine directly. If you wanted to use the simplest level 1 hosting API, you could use runtimes instead of engines and save a line of code.

The ScriptRuntime version of ExecuteFile doesn’t include an overload that takes a ScriptScope like ScriptEngine does, so instead you add the items variable to the globals scope. However, this doesn’t automatically add the items object to every child scope – you have to explicitly import items into the local scope if you want to use it. So for Python, that means you need to add “import items” to the top of the GetThings.py script. Nothing else changes.

Personally, I find DLR Hosting API Level 2 to be straightforward and easy enough to understand, so I tend to code to that level by default. I actually had to go read the doc to discover the ScriptRuntime.Globals property and talk to Dino about importing those variables into a local scope. However, I wanted to point out that nothing in my Hybrid App Debugging sample so far is really dependent on the level 2 API. If you just want to execute some Python files in the context of your C# application, you can stick with the simpler level 1 API if you want. You can even use lightweight debugging with the level 1 API – there’s an overload of the SetTrace extension method for ScriptRuntimes just as there is for ScriptEngines. Just something to keep in mind.

HawkCodeBox

Last month, I lamented the lack of extensibility of the WPF text box. While there are several vendors and at least one open source custom syntax highlighting text box, it still really bothers me how inextensible the basic WPF text box is. I just want to do a simple colorizing REPL – why is that so hard?

So instead of using any of those syntax highlighting text boxes, I decided to build my own using the approach Ken Johnson wrote about on Code Project. As I wrote before, it’s a hack – you set the text box’s foreground and background brushes to transparent so that you can override OnRender – but it works.

The big change I made from Ken’s code was to use DLR TokenCategorizer instead of regular expressions to tokenize the code. TokenCategorizer is a service provided by the DLR hosting API, which will tokenize a given script source for you. Here’s the code that colorizes the text in the text box.

As you can see, I ask the engine for a TokenCategorizer, initialize it with the text box’s current contents, then iterate thru the tokens, looking for ones in my SyntaxMap. If the token category is in the syntax map, we change the foreground brush for that span of formatted text (ft is a WPF FormattedText instance I created earlier in the method.

Of course, this approach isn’t very efficient – it re-colorizes the entire file on every change. It turns out that some DLR TokenCategorizer are restartable so you can cache the tokenizer state at any point and then return later with a new TokenCategorizer instance and pick up tokenizing where you left off. With this approach, you could say tokenize a line at a time, allowing you to only need to retokenize the line where the change occurred rather than the entire file. But only IronPython supports tokenizer restarting today, so I decided to take the easy way and simple re-colorize on every change.

I named the project HawkCodeBox and I’ve published the source up on GitHub. It’s fairly simple, but of course the goal wasn’t to build the be-all-end-all text editor – other people in the VS team already have that job.

Invoking Python Functions from C# (Without Dynamic)

So I’ve compiled the Pygments package into a CLR assembly and loaded an embedded Python script, so now all that remains is calling into the functions in that embedded Python script. Turns out, this is the easiest step so far.

We’ll start with get_all_lexers and get_all_styles, since they’re nearly identical. Both functions are called once on initialization, take zero arguments and return a PythonGenerator (for you C# devs, a PythonGenerator is kind of like the IEnumerable that gets created when you yield return from a function). In fact, the only difference between them is that get_all_styles returns a generator of simple strings, while get_all_lexers returns a PythonTuple of the long name, a tuple of aliases, a tuple of filename patterns and a tuple of mime types. Here’s the implementation of Languages property:

If you recall from my last post, I initialized the _scope on a background thread, so I first have to wait for the thread to complete. If I was using C# 4.0, I’d simply be able to run _scope.get_all_lexers, but since I’m not I have to manually reach into the _scope and retrieve the get_all_lexers function via the GetVariable method. I can’t invoke the PythonFunction directly from C#, instead I have to use the Invoke method that hangs off _engine.Operations. I cast the return value from Invoke to a PythonGenerator and iterate over it to populate the array of languages.

If you’re working with dynamic languages from C#, the ObjectOperations instance than hangs off the ScriptEngine instance is amazingly useful. Dynamic objects can participate in a powerful but somewhat complex protocol for binding a wide variety of dynamic operation types. The DynamicMetaObject class supports twelve different Bind operations. But the DynamicMetaObject binder methods are designed to be used by language implementors. The ObjectOperations class lets you invoke them fairly easily from a higher level of abstraction.

The last Python function I call from C# is generate_html. Unlike get_all_lexers, generate_html takes three parameters and can be called multiple times. The Invoke method has a params argument so it can accept any number of additional parameters, but when I tried to call it I got a NotImplemented exception. It turns out that Invoke currently throws NotImplemented if it receives more than 2 parameters. Yes, we realize that’s kinda broken and we are looking to fix it. However, it turns out there’s another way that’s also more efficient for a function like generate_html that we are likely to call more than once. Here’s my implementation of GenerateHtml in C#.

Instead of calling Invoke, I convert the PythonFunction instance into a delegate using Operations.ConvertTo which I then cache and call like any other delegate from C#. Not only does Invoke fail for more than two parameters, it creates a new dynamic call site every time it’s called. Since get_all_lexers and get_all_styles are each only called once, it’s no big deal. But you typically call generate_html multiple times for a block of source code. Using ConvertTo generates a dynamic call site as part of the delegate, so that’s more efficient than creating one on every call.

The rest of the C# code is fairly pedestrian and has nothing to do with IronPython, as all access to Python code is hidden behind GenerateHtml as well as the Languages and Styles property.

So as I’ve shown in the last few posts, embedding IronPython inside a C# application – even before we get the new dynamic functionality of C# 4.0 – isn’t really all that hard. Of course, we’re always interested in ways to make it easier. If you’ve got any questions or suggestions, please feel free to leave a comment or drop me a line.

Embedding Python Scripts in C# Applications

Now that I’ve got Pygments and its dependencies packaged up in an easy-to-distribute assembly, I need to be able to call it from C#. However, if you pop open pygments.dll in Reflector, you’ll notice it’s not exactly intuitive to access. Lots of compiler generated names like pygments$12 and StringIO$64 in a type named DLRCachedCode. Clearly, this code isn’t intended to be used by anything except the IronPython runtime.

So we better create one of those IronPython runtime thingies.

As you can see in the layer diagram to the left, PygmentsCodeSource is split into two parts – a C# part and a Python part. The Python part is very simple – just importing a couple of Pygments functions into the global namespace and a simple helper function to generate syntax highlighted HTML from a given block of code in a given language and style. The code itself is pretty simple. Note the reference to the pygments assembly I described last post. Here’s the entire file:

Instead of including this in the Pygments assembly, I embedded this file as a resource in my C# assembly. This way, I could use the standard DLR hosting APIs to create a script source and execute this code. I did have to build a concrete StreamContentProvider class to wrap the resource stream in, but otherwise, it’s pretty straight forward.

Once I got the engine and script source set up, all that remains is setup a script scope to execute the script source in. For this specific application, it’s probably overkill to have a scope per instance – I think the syntax highlighting process is stateless so a single scope should be easily shared across multiple PygmentsCodeSource instances. But I didn’t take any chances, I created a script scope per instance to execute the source in.

You’ll notice that I’m executing the source in the scope on a background thread. That’s because it takes a while to execute, especially the first time. However, I don’t actually use the Python code until after the user types or copies a block of code into the UI and presses OK. In my experience, executing the Python code is typically finished by the time I get code into the box and press OK. I just need to make sure I add an _init_thread.Join guard anywhere I’m going to access the _scope to be sure the initialization is complete before I try to use it.

In the next, and last, post in this small series we’ll see how to invoke Python functions in the _scope I initialized above from C#.

Compiling Python Packages into Assemblies

In looking at my hybrid IronPython / C# Windows Live Writer plugin, we’re going to start at the bottom with the Pygments package. Typically Python packages are a physical on-disk folder that contain a collection of Python files (aka modules). And during early development of Pygments for WLWriter, that’s exactly how I used it. However, when it can time for deployment, I figured it would be much easier if I packaged up the Pygments package, my custom HTML formatter and the standard library modules that Pygments depends on into a single assembly.

IronPython ships with a script named pyc for compiling Python files into .NET assemblies. However, pyc is pretty much just a wrapper around the clr module CompileModules function. I wrote my own custom script to build the Pygments assembly from the files in a the pygments and pygments_dependencies folders.

Most of this code is a custom implementation of walk. I have all the IronPython and DLR dlls including ipy.exe checked into my source tree, but I don’t have the standard library checked in. Other than that, the code is pretty straight forward – collect a bunch of files in a list and call CompileModules.

The problem with this approach is that IronPython isn’t doing any kind of dependency checking when we compile the assembly. If you pass just the contents of the Pygments package into CompileModules, it will emit an assembly but that assembly will still depend on some modules in the standard library. If those aren’t available, the Pygments assembly won’t load. I’d love to have an automatic tool to determine module dependencies, but since I didn’t have such a tool I used a brute-force, by-hand solution. I wrote a small script to exercise the Pygments assembly. If there were any missing dependencies, test_compiled_pygments would throw an exception indicating the missing module. For each missing dependency, I copied over the missing dependency, recompiled to project and tried again. Lather, rinse, repeat. Not fun, but Pygments only depended on seven standard library modules so it didn’t end up taking that long.

So having gone down this path of compiling Python files into an assembly, would I do it again? For an application with an installer like this one, yes no question. I added the Pygments assembly as a reference to my C# library and it got added to the installer automatically. That was much easier than managing all of the Pygments files and its dependencies in the installer project manually. Plus, I still would have had to manually figure out the dependencies unless I chose to include the entire standard library.

I will point out that the compiled Pygments assembly is the largest single file in my deployed solution. It clocks in at 2.25MB. That’s about twice the size of the Python files that I compiled it from. So clearly, I’m paying for the convenience of deploying a single file in space and maybe load time. [1] I’m also paying in space for a private copy of IronPython and the DLR – the two IronPython and five DLR assemblies clock in around 3.16MB. In comparison, the actual Writer plugin assembly itself is only about 25KB! But for an installed desktop app like a WLWriter plugin, 5MB of assorted infrastructure isn’t worth worrying about compared to the hassle of ensuring a shared copy of IronPython is installed. I mean, even if you don’t know IronPython exists, you can still install and use Pygments for WLWriter. Simplifying the install process is easily worth 5MB in storage space on the user’s computer in my opinion.

Next up, we’ll look at the Python half of the PygmentsCodeSource component, which calls into this compiled Pygments library.

[1] I haven’t done it, but it would be interesting to compare the load time for the single larger pygments assembly vs. loading and parsing the Python files individually. If I had to guess, I’m thinking the single assembly would load faster even though it’s bigger since there’s less overhead (only loading one big file vs. lots of small ones) and you skip the parsing step. But that’s pure guesswork on my part.

Building a Hybrid C# / IronPython App Without Dynamic Type

Arguably, the biggest feature of C# 4.0 is the new dynamic type. And it’ll be great…when it ships. In the meantime, some of us what to build hybrid C# and IronPython applications today, such as my Pygments for Windows Live Writer plugin.

Pygments is a syntax highlighter, written in Python, with support for over one hundred languages. With the exception of a couple of bugs in our importer (discussed here) it works great with IronPython. It’s also extensible, so I was able to easily build a custom formatter to output exactly the HTML I want inserted in my blog posts. So it made perfect sense to use Pygments as the basis of a Windows Live Writer plugin.

As great a tool as Windows Live Writer is, it’s developers haven’t exactly seen the light when it comes to dynamic languages. If you want to create a custom Content Source for Windows Live Writer, you have to generate a compiled on-disk assembly with a static type and custom attributes. Not exactly IronPython’s forte, if you know what I mean. I did try and build a pure IronPython solution, but eventually gave up. So I ended up building a hybrid solution. The front end of the plugin as well as the UI elements are written in C# while the syntax highlighter engine is written in IronPython. And since this is running on the current .NET framework, I didn’t have the new fangled C# 4.0 dynamic type to help me.

Over the next couple of blog posts, I want to highlight a few aspects how I built this plugin, including compiling Python packages into assemblies and invoking Python code from C# 3.0 and earlier. If you want to look for your self, the source is up on GitHub.

AgDLR 0.5

I mentioned yesterday that it looked like a new release of AgDLR was eminent and sure enough here it is. There are some really cool new features including Silverlight 3 Transparent Platform Extension support, In-Browser REPL and In-Browser testing of Silverlight apps. As with IronRuby 0.3, Jimmy has the a summary of the new AgDLR release.

One feature of the new release I did want to highlight was XapHttpHandler because I’m the one who wrote it! :)

The Silverlight versions of IronPython and IronRuby ship with a tool called Chiron that provides a REPL-esque experience for building dynamic language Silverlight apps. John Lam had a good write-up on Chiron when we first released it last year, but basically the idea is that Chiron is a local web server that will auto-generate a Silverlight XAP from a directory of Python and/or Ruby files on demand. For example, if your HTML page requests a Silverlight app named app.xap, Chiron automatically creates the app.xap file from the files in the app directory. This lets you simply edit your Python and/or Ruby files directly then refresh your browser to get the new version without needing an explicit build step.

The problem is that, unlike IIS and the ASP.NET Development Server, Chiron doesn’t integrate with ASP.NET. So it’s fine for building Silverlight apps that stand alone or talk to 3rd party services. But if you want to build a Silverlight app that talks back to it’s ASP.NET host, you’re out of luck. That’s where XapHttpHandler comes in. XapHttpHandler does the same exact on-demand XAP packaging for dynamic language Silverlight applications that Chiron does, but it’s implemented as an IHttpHandler so it plugs into the standard ASP.NET pipeline. All you have to do is put the Chiron.exe in your web application’s bin directory and add XapHttpHandler to your web.config like so:

<configuration>
  <!--remaining web.config content ommitted for clarity-->
  <system.web>
    <httpHandlers>
      <add verb="*" path="*.xap" validate="false" type="Chiron.XapHttpHandler,Chiron"/>
    </httpHandlers>
  <system.web>
</configuration>

The new AgDLR drop includes a sample website that shows XapHttpHandler in action.

Quick note of caution: by design, XapHttpHandler does not cache the XAP file - it’s generated anew on every request. So I would highly recommend against using XapHttpHandler on a production web server. You’re much better off using Chiron to build a physical XAP file that you then deploy to your production web server.

IronPython Nightly Builds

IronPython 2.0 shipped about a month ago, but we’re still chugging along with our post 2.0 work. We’ve shipped seven source code releases since we shipped 2.0 and we should be back to our normal schedule of updating the source 2-3 times a week schedule by next week. Given how often we ship source, we’re thinking of extending the the time between binary drops. Binary releases have to be signed and there’s a fairly arduous process we have to go thru in order to get each binary release out the door.

However, there’s something nice and convenient about downloading a pre-compiled binary release. So I spent my Christmas vacation building a script to download and build IronPython nightly builds. Once built, I compress the binaries and upload them to Azure blob storage. Finally, I built a *very* simple cloud app for users to view and download available nightly builds. As an extra benefit, I’m also providing nightly builds of the DLR.

Please note, these are *NOT* official Microsoft releases of IronPython and/or DLR. They aren’t signed and they haven’t gone through the aforementioned release process. I’m just downloading the public source, building it with the publicly available tools, then making them available on a a publicly accessible website.

The website for the IronPython (and DLR) nightly builds is http://nightlybuilds.cloudapp.net.

As usual, I welcome any feedback. Is having prebuilt unsigned binaries of IPy releases useful? Do you want IronRuby binaries as well? What about social features (rating releases, comments, etc)? Please let me know what you think.

IronPython RTM News Gets Around

I just hit the MSDN home page, and what should I see?

It’s cool to see JasonZ, aka my group’s general manager, blogging about our product.

I also fired up Visual Studio, and IronPython is the top headline there too:

Not sure why the news is dated September 18th, but hey it’s really cool to see IronPython (not to mention the DLR, with the second headline) getting this kind of visibility.

Early Christmas from Iron Languages and DLR

Tomorrow may be Thanksgiving, but the Microsoft DevDiv dynamic language teams are trying to make it feel like Christmas with three separate pre-holiday releases.

1. IronPython 2.0 RC2 
   We were really hoping to only have one release candidate, but we ended up with a couple of significant bugs that we couldn’t push off to 2.0.1. With December holidays coming soon, RC2 has a pretty small window before we declare RTM so now is the time to download the release and try your code out.
2. IronRuby 1.0 Alpha 2 
   There’s been zero blog traffic on this, just a notice on the IronRuby mailing list. As per said notice, “Notable features” include “the inclusion of iirb.bat, igem.bat, irails.bat, irake.bat”.
3. New DLR CodePlex Project T
   he DLR source has been available as part of IronPython for over a year but now they have their own home on CodePlex. Check out the Release Notes for an overview, reads some Docs and Specs or just download their initial v0.9 beta. Their v0.9 beta is synced with IPy 2.0 RC2 (and their v0.9 final will sync with IPy 2.0 RTM) but it also includes synced versions of IronRuby and ToyScript in both source and binaries. Plus, Sesh has promised “weekly code drops”. Finally, unlike IronPython and IronRuby, DLR is using the discussion section of their CodePlex site – I’m eager to see how well the new-ish discussion/mailing list integration works.

So there you go, new versions of IronPython and IronRuby plus a whole new DLR CodePlex project to boot. Enjoy.

The Fifth Assembly

As I’ve written previously, we’ve had a few challenges recently with name collisions in the DLR. In that post, I described how we had solved – or thought we solved, as it turned out – the problem with ExtensionAttribute name collisions between Microsoft.Scripting.Core.dll and System.dll.

However, as it turns out, having lots of copies of the same type didn’t solve the problem. Since ExtensionAttribute is a known type to the C# 3.0 compiler, it has to choose one of the multiple copies that are in the project. We thought that given a choice, it would favor the System.Core version. However, what folks discovered after we released Beta 5 is that C# 3.0 will choose the first copy of ExtensionAttribute that it finds. So if you have System.Core.dll and IronPython referenced in your project, and you define your own extension methods, the compile fails if the C# 3.0 compiler finds one of the IronPython or DLR private copies of ExtensionAttribute before the public copy in System.Core.

Furthermore, there doesn’t seem to be any way to set the reference order in MSBuild files. I’ve never dug deep into the MSBuild file format, but changing the order of the references in the csproj file didn’t seem to effect the order the references were passed to the C# compiler. I’m guessing we might be able to change this by fiddling with the ResolveAssemblyReference task, but we didn’t want to force low level MSBuild file hacking on our user base.

We looked at a variety of other solutions, including rewriting the IL after compilation to change the namespace of the ExtensionAttribute. However, we had trouble making that solution work and besides, changing the ExtensionAttribute namespace would have broken anyone using the existing DLR or IPy extension methods. So instead, we went with a different solution that we like to refer to as “The Fifth Assembly” around the office.

In IronPython 2.0 Beta 5, there were four DLLs that implement IronPython: IronPython.dll, IronPython.Modules.dll, Microsoft.Scripting.dll and Microsoft.Scripting.Core.dll. In our RC1 release, we’ve added “The Fifth Assembly”: Microsoft.Scripting.ExtensionAttribute.dll. As you might guess from its name, it has only a single public type: ExtensionAttribute. By having ExtensionAttribute in its own dedicated assembly, we can avoid the type collision at compile time by not referencing both System.Core.dll and Microsoft.Scripting.ExtensionAttribute.dll in the same project.

In IronPython, we reference the ExtensionAttribute assembly because we use the C# 3.0 complier but IPy has to be able to run on .NET Framework 2.0 SP1. However, projects that embed IronPython in a .NET 3.5 project (aka C# 3.0 or VB 9.0) will reference System.Core instead. The only reason why you would explicitly use the ExtensionAttribute assembly was that if you, like us, wanted to build your app with .NET 3.5, use extension methods but still be compatible with .NET 2.0 SP1. We’re guessing there aren’t many of our customers doing that, but if you are, explicitly referencing ExtensionAttribute will work just as it does for compiling IronPython itself.

It’s important to remember two things about the Fifth Assembly:

1. Never reference System.Core and Microsoft.Scripting.ExtensionAttribute in the same project.
2. Always deploy Microsoft.Scripting.ExtensionAttribute.dll as part of any solution that embeds IronPython (or IronRuby or vanilla DLR for that matter), even if you don’t reference it explicitly within your project.

This change is public in the source code as of change set 42076 and will also be in the nearly-ready RC1 release of IronPython 2.0. If you’ve got any questions or <shudder> find any more issues with this solution, please let us know right away.

DLR Namespace Change Fire Drill

[Ed. Note – This long post is about changes we made in the DLR to avoid type collisions with System.Core. The short version of this post is “You can safely ignore the CS1685 warning you’ll get if you embed IPy 2.0 Beta 5 or later in your C# 3.0 application”. The long version below has the gory details of what we did, why we did it, a little about how extension methods work and why you can ignore warning CS1685.]

[Author note – I don’t really have an editor.]

Between Beta 3 and Beta 4 of IronPython 2.0, the DLR team made a very significant change to Microsoft.Scripting.Core.dll. As JB noticed, the DLR expression trees have merged with the LINQ expression trees. As part of this effort, they moved the newly merged expression tree types in Microsoft.Scripting.Core.dll into the System.Linq.Expressions namespace – the same namespace where those types live in System.Core.dll in .NET Framework 3.5.

This change caused quite a few issues with our users. Basically, because of the expression tree merge and the namespace change, the beta 4 version of Microsoft.Scripting.Core.dll had type collisions with System.Core.dll all over the place, making it hard or impossible to use them together. If you're using C# you could get around these type collisions by using an assembly reference alias. However, assembly reference aliases aren’t supported for Web Sites projects or in Visual Basic.

To fix this, we're changing the top level namespace in Microsoft.Scripting.Core.dll from System to Microsoft. We're not going back to the namespaces as they were in Beta 3 - for example, DLR expression trees were originally in the Microsoft.Scripting.Ast namespace but now they'll be in Microsoft.Linq.Expressions. We don't think this change will be much of an issue because most people don't use types from Microsoft.Scripting.Core.dll directly. Unless you're building your own DLR language, this namespace change shouldn't affect you at all except to solve the type collision problem.

However, we did hit a small snag.

The LINQ expression tree code, having been written for .NET 3.5, is a heavy user of extension methods. This means IronPython is now also a heavy user of extension methods. However, unlike LINQ, IronPython has to run against .NET 2.0 SP1. That means we can't reference System.Core.dll in IPy or DLR. If you try to compile C# code with extension methods but without a reference System.Core.dll, you get a compiler error complaining that it can't find the required ExtensionAttribute type, which is defined in System.Core.dll.

This might appear to be an unsolvable problem, but it turns out the C# compiler doesn't actually care where the ExtensionAttribute type comes from. You can actually define your own copy of ExtensionAttribute (in the right namespace) and C# will happily compile extension methods without complaint. Furthermore, ExtensionAttribute is only used as a marker - there's no real code in it - so implementing your own copy is trivial. In the DLR source, you'll find they have defined their own copy of ExtensionAttribute so they can use extension methods and remain .NET 2.0 SP1 compatible. Since we were using them in Microsoft.Scripting.Core.dll, we started using extension methods in Microsoft.Scripting.dll and IronPython.dll as well.

If you'll recall back to the start of this post, we're changing namespaces in order to eliminate type collisions. The snag we hit was that we couldn’t change the ExtensionAttribute namespace without breaking all the extension methods. But we couldn’t leave it the same without having a type collision with the ExtensionAttribute defined in System.Core.dll. If you had a project including both copies of ExtensionAttribute, C# would generate a multiple type definition warning and VB would generate a multiple type definition error.

We've looked at a several possible solutions to this. One idea was to ship two completely different sets of binaries - one for .NET 2.0 and one for .NET 3.5. But the upgrade story for that stinks - you want to upgrade your app to .NET 3.5 you have to swap out all your IPy and DLR dlls. Yuck. We considered having separate copies of just Microsoft.Scripting.Core.dll - one defining ExtensionAttribute and the other linked to System.Core.dll and using TypeForwardedTo - but since the assemblies are strongly typed they'd have to same exact version number in order to be swappable. Double yuck.

In the end, we decided to put an internal copy of ExtensionAttribute in each assembly that needs it. As previously indicated, that's IronPython.dll and Microsoft.Scripting.dll as well as making the copy already in Microsoft.Scripting.Core.dll internal. For IronRuby fans reading this, we also added a copy of ExtensionAttribute to IronRuby.dll and IronRuby.Libraries.Scanner.dll as well.

It seems counterintuitive, doesn't it? To solve a multiple type definition problem, we defined even more copies of the type in question.

The key thing is that all these copies of ExtensionAttribute (except the one in System.Core.dll) are internal rather than public types. If you build a VB app that references System.Core.dll and Microsoft.Scripting.Core.dll (beta 4), you end up with multiple public copies of ExtensionAttribute and are rewarded with a VB compiler error. However, as long as there's only one public copy of ExtensionAttribute - regardless of the number of internal copies of that type - VB is happy. So if you're building a VB app against Microsoft.Scripting.Core.dll (beta 5) and System.Core, you should be golden.

In C# 3.0, on the other hand, continues to throw a warning. If ExtensionAttribute was a user-defined type, we'd be fine. However, since Extension attribute is a "predefined system type", you get C# warning 1685 even though the copies of ExtensionAttribute are all internal. Furthermore, since there are multiple internal copies of ExtensionAttribute in the IPy dlls, you'll get this warning even if you're not referencing System.Core. It seems here that C# 3.0 considers ExtensionAttribute a predefined system type while VB doesn't.

I realize that always having a warning in C# 3.0 - even if you're not referencing System.Core.dll - doesn't feel particularly clean. Given our desire to support both .NET v2 and v3.5 with the same binaries, it was the only choice. Remember that ExtensionAttribute has literally no code and is only used to signal the compiler for extension methods, so we decided it was fairly ignorable as warnings go.

If you're willing to compile from source yourself, it's fairly easy to build a set of binaries for a specific version .NET that doesn't have the warning. If you're building for v3.5, you need to remove Extension.cs from the three projects that have a copy of it (Microsoft.Scripting.Core, Microsoft.Scripting, IronPython) and add a reference to System.Core.dll. If you're building for v2.0, remove the Extension.cs from Microsoft.Scripting and IronPython then change the visibility in the Microsoft.Scripting.Core version from internal to public. Note, we treat warnings as errors in IPy, but we did add CS1685 to the list of WarningsNotAsErrors so the code still compiles. Of course, if you’re defining a framework specific version, you won’t get the warning anyway.

As usual, we appreciate all feedback from our community so hammer on this build as much as you can - esp. if you've been having type conflict errors with Beta 4. As I said in an earlier post, this is our last planned beta, so now’s the time put it thru the paces to make sure there’s nothing blocking you before we get to 2.0.

Finally, major props to Curt...aka IRON CURT...for driving these dev changes and putting up with the constant barrage of "where are we now?" status requests from yours truly. I'm sure he now regrets sitting across the hall within easy earshot.

Afternoon Coffee 174

You know, this gets pretty long when I go a week between morning coffee posts.

Dynamic Language Stuff

• There's a new version of the DLR Hosting spec. One of the biggest changes is the removal of DLR's pre-canned knowledge of IPy and IRuby. Now, you use app.config to specify DLR languages and map them to extensions. Sesh has the details and a sample. If you only care about hosting IPy, you can use our language specific hosting API which doesn't require app.config.
• Jimmy pushed out a new version of the Silverlight Dynamic Languages SDK. He's on the lookout for a better name, one of his commenters suggested "SilverWhisper Kit".
• Srivatsn shows how to pass Python keyword arguments to a C# method using ParamDictionaryAttribute, similar to how C# supports the params keyword via the ParamArrayAttribute. Unfortunately, there's no syntactic sugar for calling param dictionary methods from C#. I wonder, do most people like or dislike the idea of language level support for keyword arguments in C#? I'm guessing most would be against, though I think it's a cool idea.
• Maybe it's me, but I've noticed an uptick in twitter posts containing "ironpython" of late. For example, via Summize I discovered Joseph Jude's blog finally{} where he has posted a time tracking tool he built in IPy as well as his initial IPy learnings.
• Michael Foord, as usual, has been generating quite a bit of good IPy content. He did a tutorial on IPy at PyCon UK,  his book is almost done, he has some interesting thoughts on dynamic language performance and even admits that he likes C#, though not as much as he likes Python.
• Vernon Cole announced that the adodbapi project now supports IronPython 2.0 as well as CPython. This library is a DB-API 2.0 compliant interface for any database that support ADO (note, that's native ADO not ADO.NET). I love to see Python projects with explicit support for IPy.
• My boss - who apparently will be called "Rem" from now on in the office - saves you "gazillions" by explaining non-positional negotiating strategy and draws the comparison to agile software development. Not exactly related to dynamic languages, but I'd like to see him further explore the relationship super-optimal, non-positional, significantly-hyphenated negotiation and software design. (OK, I made up "significantly-hyphenated")

Other Stuff

• Don Syme blogs about an update to the F# CTP, a mere week after the original release. One week? That's more often than even IPy releases. I can't wait to see what they ship in next week's release! :) Seriously, I hope they can keep the release sprints short, but every week would be a bit crazy!
• Speaking of F#, Matt Podwysocki updates FsTest for the F# CTP and posts about Extension Everything in F#. Unlike C#, which only supports extension methods, F# also supports extensions properties, static methods and events, though like Matt I can't think of a good use for extension events.
• Still speaking about F#, Andrew Kennedy has a three part series on the new units of measure feature of F#. If you were going to use F# to build the physics engine of a game, I would suspect UoM would be extremely useful. (via Don Syme)
• Oh look, Chris Smith built an F# version of artillery game that uses Units of Measure for the physics code. I'll bet UoM was extremely useful. :)
• Talking about Live Mesh at TechEd Australia - where much to my surprise frankly they were demoing Live Mesh Apps - I pointed out to Scott Hanselman that Mesh is running an embedded CoreCLR (aka the same CLR from Silverlight 2). Scott went poking around and posted what he discovered. Looking forward to finding out what he digs up on using CoreCLR outside the browser.
• Speaking of Scott, I need to set up a family video conference solution like Scott's before my next trip.
• Congrats to Glenn Block and the MEF team for their initial CodePlex source drop! I've been hearing about this possibility since Glenn joined the team, so I'm really excited to see it happen. I need to take a look at it in detail (in my copious spare time) because I want to find out how to make it work with IPy.
• Bart de Smet has a whole series (starting here) on Dynamic Expression Trees. However, given that he specifically writes "This blog series is not about DLR itself" makes it seem pretty conceptual to me. Why not talk about DLR expression trees instead Bart?
• I'm sure you noticed ASP.NET MVC preview 5 dropped last week. I really liked Brad Wilson's discussion of the new view engine design.
• Tomas Restrepo has started publishing his source code on GitHub. Personally, I haven't published any source code lately but I am using Git for all of my non IPy core work (which is stored in TFS). Like Tomas, I'm still getting the hang of Git but I'm really digging it's speed, it's branching and the fact that there's zero infrastructure requirements. SVN provides the lightweight svnserve, but Git is even lighter weight than that.
• I liked Steve Yegge's post on typing. I am a touch typer, but I doubt I type 70 words a minutes. I do know where the number keys are without looking though, so I guess that's pretty good. I remember seeing Chris Anderson demo Avalon WPF long before it was public and being impressed at how fast he could type.

Five Minutes Past Noon Coffee 170

• Ben Hall announces IronEditor, a simple dev tool for IronPython and IronRuby. Pretty nice, though fairly simplistic (as Ben readily admits). For example, it doesn't have an interactive mode, only the ability to execute scripts and direct the output to IronEditor's output window. However, it is a good start and I'm sure it'll just get better. One thing he's apparently considering is a Silverlight version. (via Michael Foord)
• Speaking of "Iron" tools, Sapphire Steel have had an IronRuby version (in alpha) of their Ruby in Steel product for several months now. I wonder if John's had a chance to play with it.
• Speaking of John, the ASP.NET MVC / IronRuby prototype he talked about @ TechEd is now available on ASP.NET MVC Preview 4 via Phil Haack.
• Ted Neward has an article exploring the IronPython VS Integration sample that ships in the VS SDK. As I mentioned the other day, we're starting working on a production quality implementation of VS Integration for IPy.
• Ophir Kra-Oz (aka Evil Fish) blogs Python for Executives. I like his "Risk, Recruiting, Performance and Maturity" model - four boxes, perfect for keeping an executive's attention! :) Plus Ophir has some nice things to say about IronPython. (via Michael Foord)
• Ronnie Maor blogs an extension method for PythonEngine to make Eval simpler. I especially like how he uses string format syntax so you can dynamically generate the code to eval. I wonder what this would look like in IPy 2.0 with DLR Hosting API. (via IronPython URLs)
• Speaking of DLR Hosting, Seshadri has another great DLR hosting post, this time hosting IPy inside of VS08 so you can script VS08 events (document saved, window created, etc) with Python.
• Justin Etheredge has a bunch of IronRuby posts - Getting IronRuby Up and Running, Running Applications in IronRuby, Learning Ruby via IronRuby and C# Part 1. (via Sam Gentile)
• Don Syme links to several F# related posts by Ray Vernagus, though he's apparently also experimenting with IronRuby. I'm really interested in his Purely Functional Data Structures port to F#.
• Speaking of F#, Brian has a teaser screenshot of F# upcoming CTP. However, he chooses the New Item dialog to tease, which looks pretty much like the current new item dialog (the new one does have fewer F# templates). However, if you look in the Solution Explorer, you'll notice a real "References" node. No more #I/#R! Yeah!
• The interactive graphic in Kevin Kelly's One Machine article is fascinating. It really highlights that the vast vast vast majority of power, storage, CPU cycles and RAM come from personal computers on the edge. Even in bandwidth, where PC's still have the highest share but it looks to be around 1/3rd, the aggregate of all edge devices (PCs, mobile phones, PDAs, etc.) still dominates the data centers.

Morning Coffee 169

• Check out the crowd for a the Washington Capitals developmental camp scrimmage last week (My parents are in their somewhere). Standing room only in the practice facility to watch a bunch of kids, most of whom won't ever make it to the NHL, in July. If you think Washington can't be a hockey town, you are sorely mistaken.
• Speaking of the Caps, they are establishing a "spirit squad"? Is that really necessary? (short answer: no). Peerless' take is hilarious.
• Seshadri Vijayaraghavan is a tester on the DLR team and he's been writing quite a bit about the DLR hosting API. He's got a series of posts about hosting, invoking and redirecting output from IronPython in a C# application.
• I haven't seen an official announcement, but mobile access to Live Mesh is available by pointing your phone browser to http://m.mesh.com. It's mostly a web view of the Live Desktop, though there is a feature to upload photos from your phone. However, for some reason that feature doesn't work for me right now. I don't get the "browse" button.
• ASP.NET MVC Preview 4 is available for download. Phil Haack has a few details that ScottGu didn't cover. Scott Hanselman shows off some AJAX stuff.
• Speaking of Scott Hanselman, he highlights the return of Terrarium from Bil Simser. Scott mentions that most Terrarium animal implementations were big collections of nested if statements. I wonder if F# pattern matching would be a cleaner approach?
• Ted Neward obviously never "even tangentially" touched politics, as I think they have far worse flame wars far more often than we have in the software industry. However, certainly the Scala flame war he's commenting on seems fairly counterproductive.
• Brad Wilson runs into a wall trying to convert a string to an arbitrary Nullable<T>.He doesn't find an answer, but I found reading thru the steps he took to try and find an answer strangely compelling.
• Jeff Atwood argues that Maybe Normalization isn't Normal. It's mostly a collection of information from other places, including a compilation of high-scale database case studies. But it's a useful collection of info and links, with a little common-sense thrown in for good measure.
• I have a hard time imagining Pat Helland camping.

Morning Coffee 166

Yes, I realize it’s been a while. I tried in vain to catch up with my blog reading after my Hawaii vacation and finally just gave up and hit “mark all as read”.

Dynamic Languages

• There's a new version of the DLR hosting spec available (doc, pdf). The DLR implementation is still in motion, so there are some inconsistencies between the spec and the code, but the spec should give you the high level overview you need if you want to host DLR languages inside your app.
• Oleg Tkachenko recently joined the dynamic languages team. He's the creator of the Interactive IronRuby Web Shell, an IronRuby version of Try Ruby. Of course, it’s not as cool as using SL2to execute the code directly in the browser. Michael Foord has his Python in the Browser and my teammates John and Jimmy demoed a Silverlight version of Try Ruby @ TechEd.
• Jim Deville, also of the dynamic languages team, recently started blogging.
• I have a new boss, Dave Remy. He doesn't have a blog - yet - but you can follow him on Twitter as daveremy. When Twitter is actually working that is.
• There's a new homepage/wiki for IronRuby though I’m not sure why there's a picture of Matz wearing a Python shirt on the home page.
• My teammate Jimmy Schementi provides some "continued hope" for a better (heck, I'll take current) ASP.NET and ASP.NET MVC story for DLR languages.
• Via Michael Foord, sounds like IronClad is making good progress. V0.4 can run the bz2 module "in its entirity" (maybe run a spellcheck on your site, guys?) and now apparently, it's now able to load numpy.core. Very exciting!

Other Stuff

• Pat Helland, who has blogged even less than me for the past few months, has a post up about controller and doers in the IT department. After 18 months in MSIT, put me in the doer camp, please.
• The F# team has pushed out a spec for v1.9.4 of the language. Don Syme says it's not official, but it's a huge improvement over the old informal spec
• Speaking of F#, my friend Matthew Podwysocki recently published FsTest, a testing DSL for F#. I wrote about F# unit testing as part of my PEG parsing series, and I really like the direction Matthew has taken this project. You can pull it down from CodePlex.
• When I did my PEG talk @ Lang.NET, Gilad Bracha mentioned I should check out oMeta. It looks really cool, though with the job change I haven’t had the time to play with it. Now I discover that Jeff Moser is working on a version for CLR called oMeta# that I’ve got to spend some time with. And in the comments to that post, I discovered pyMeta from Allen Short, though it apparently doesn’t work on IronPython (must investigate why).
• James Kovacs introduces psake, a PowerShell based build automation tool which uses a rake-inspired internal DSL syntax similar to one I blogged last year. I'd love to see this take off, but given MSBuild's tool integration, I wonder if that's feasible.
• I upgraded my home wireless network almost exactly a year ago. I've been happy with the range and coverage, but not so happy with the Buffalo Tech firmware. The built-in DHCP server is pretty flaky. So I upgraded to the open-source Tomato firmware. Upgrade was smooth, though I did need to reset my cable modem. But even that was smooth - Comcast has an automated service for that now,

Programming Languages @ PDC08

The PDC folks pushed out a bunch of new sessions yesterday, including a bunch from my part of DevDiv. You can see the full list of sessions that have been published (so far) at the PDC site.

An Introduction to F#
Learn about Microsoft's new language, F#, a typed functional programming language for the .NET Framework. F# combines functional programming with the runtime support, libraries, tools, and object model of .Net. Understand how F# asynchronous workflows help tame the complexity of parallel and asynchronous I/O programming and how to use F# in conjunction with tools such as Parallel Extensions for .NET.

Deep Dive: Dynamic Languages in .NET
The CLR has great support for dynamic languages like IronPython. Learn how the new Dynamic Language Runtime (DLR) adds a shared dynamic type system, a standard hosting model, and support for generating fast dynamic code. Hear how these features enable languages that use the DLR to share code with other dynamic and static languages like VB.NET and C#.

Future Directions for Visual Basic
Come learn about the new capabilities in the next version of the language, including: extensions to LINQ, syntax simplifications, and improvements to the IDE. We'll provide insight into the direction of the language, including dynamic binding, meta-programming, and scripting.

The Future of C#
In this talk Microsoft Technical fellow and C# Chief Architect Anders Hejlsberg outlines the future of C#. He will describe the many forces that influence and shape the future of programming languages and explain how they fit into C#.

Visual C++: 10 is the New 6
Get more done. The next version of Visual C++ is all about improving developer productivity for large-scale applications. Learn about the IntelliSense and browsing experiences, changes to the project and build system, project-less browsing, collaboration through remote symbol indexing, and custom visualization of symbolic information.

Morning Coffee 164

• Big news since my last Morning Coffee post was the announcement of Live Mesh. I've been running it for about a month, and I'm really digging it. Make sure you check out the team blog and watch the developer tour video (be on the lookout for IPy about half way thru the video)

ALT.NET

• I had a great time @ the ALT.NET open space conference last weekend. I was somewhat distracted on Saturday as due to a family communication mixup, I had to bring my son Patrick with me. Jeffrey Palermo shot a cute video of him (3 minutes in) where he explains that he's at the conference "to be with my dad". Having a five year old is a little distracting, but everyone was amazingly cool with having him around. When he gets a little older I have no doubt he'll be attending conferences and leading open sessions.
• I did a session on F#, but it felt kinda all over the place. I hadn't touched F# in a few months and it showed IMO. Matt Podwysocki was there to help keep the session from devolving into mass chaos. Thanks Matt.
• My favorite session of the conference was Scott Hanselman's "Are We Innovating?" talk, which I think originated from a question I asked him: There are many examples of large OSS projects in other dev communities that get ported to .NET (NHibernate, NAnt, MonoRail, etc). Can you name one that's gone the other way? I can't.
• I took Matt's advice and joined the local ALT.NET Seattle group.

DyLang Stuff

• Martin Maly posts about how dynamic method dispatches are cached in three different layers by the DLR. You shouldn't care about this stuff if you're a DLR language user, but you will certainly care about it if you're a DLR language builder.
• I'm really excited to see Phil Haack (whom I met F2F @ ALT.NET) is experimenting with IronRuby & ASP.NET MVC. True, I'd rather it was IPy, but his Routes.LoadFromRuby would work with Python with very little code change.
• Note to self, take a deeper look at Twining, the IPy database DSL by David Seruyange.
• Daily Michael Foord - Ironclad 0.2 Released. Ironclad is a project to implement Python's C extension API in C# so that IronPython could load standard Python C modules like SciPy and NumPy. So far, they're able to load the bz2 module. 

Other Stuff

• Congrats to Brad and Jim for shipping xUnit.net 1.0.
• Everyone seems to be jumping on the functional C# coding bandwagon. Bart De Smet's series on pattern matching in C# is currently at eight posts. Now Luca Bolognese is in on the action, with three posts so far on functional code in C#. I like how Luca keeps writing that the C# syntax is "not terrible" for functional programming. Again, why suffer thru the "not terrible" syntax when you could be using F# instead? (via Charlie Calvert)
• I need to take a look at VLinq. Charlie and Scott Hanselman both mentioned it recently.
• I would like to have been in the conversation with Ted Neward, Neal Ford, Venkat Subramaniam, Don Box and Amanda Silver.
• I haven't had any time to play with XNA of late, which means the great list of GDC videos Dave Weller posted on the XNA team blog will remain beyond my ability to invest time for now.
• There's a new drop of Spec# from MS Research. IronRuby is using Spec# heavily as I recall.

IronPython 2.0 Beta 1 Released

I'm sitting in the PyCon keynote right now, but I wanted to take a quick second to say congrats to my new teammates for getting the brand spanking new beta 1 drop of IronPython 2.0. You can find out what's new via the release notes.

Joining the Dynamic Languages Team

After nearly two years in MSIT and six years focused on architecture across three different roles, I'm moving on to a new job in the Developer Division. In a couple of weeks, I'll be joining the Dynamic Languages team as a program manager. This is the team who ships IronPython, IronRuby, the Dynamic Language Runtime and Dynamic Silverlight. After seeing all the their cool work at Lang.NET this year, I just had to be a part of it.

As you might imagine, I'm pretty excited about this opportunity.

In the short term, I'll be primarily focused on IronPython, which is marching towards their 2.0 release. Towards that end, I'm attending PyCon 2008 in Chicago this weekend, though I don't officially change jobs for a couple more weeks. Longer term...well let's just say I'm going to be really focused on doing my part to get IPy 2.0 out the door and after that we'll see where things lie. This is a pretty big shift for me, so I'm explicitly trying to focus on short term work for the first six months in order to absorb as much knowledge as possible from the folks I'll be working with like Jim Hugunin, John Lam, Martin Maly, Jimmy Schementi and a bunch of others who I haven't met yet.

While this is a pretty big role shift, I haven't given up my passion for services and/or architecture. In other words, this isn't the last you'll hear about Kitchen Sink Variability, the ROI of EA or my perspective on Nick's Shared Integration Model. Obviously, with the job focus change, I expect focus on my blog to change as well. I'm not exactly sure how blogging fits into this new role, though the Dynamic Languages team is pretty open and many other members blog (as linked above) so I doubt I'm going anywhere. I'm going to try and keep blogging Morning Coffee, but I'm guessing it won't be quite as regular as it has been in the past. Unfortunately, I am going to stop coding F# for a while (sorry, Don!) I can't focus on learning two languages at once and obviously Python is my new top priority.

I wasn't in my MSIT architect role that long, but I feel that the "in the trenches" experience will serve me greatly for years to come. And of course, I will miss my teammates, especially Dale  who regular readers might remember from filling in around here occasionally.

Morning Coffee 154

• Did you see yesterday's Dilbert cartoon? Classic.
• MIX isn't the only Microsoft conference this week. It's also time for the annual MS Research TechFest conference. It actually started yesterday, with a keynote from Rick Rashid and Craig Mundy (available on demand). I'll be heading up there later today and will blog everything I saw that is public, like I did last year. In the meantime, you can check out some cool MS Research projects on the TechFest video page.
• Speaking of MS Research, they've published the Singularity source code (for academic and non-commercial purposes) on CodePlex. Singularity is research OS "focused on the construction of dependable systems". I've wanted to play with this, but I've never had the time. Frankly, that hasn't changed, but now that it's available to the community, I'm hoping I can live vicariously thru other people hacking around with it.
• Some announcements coming out of MIX won't be a surprise to anyone:
  • The IE Team blog has been discussing IE8 quite a bit of late, and the folks of LiveSide are reporting the IE8 Readiness Toolkit is already up (download links aren't live yet). There are also a bunch of developer whitepapers on Code Gallery. Update: the install links are live.
  • Scott Guthrie already announced that Silverlight 2.0 would go beta at MIX, and Neo @ SilverlightExamples has all the links for the runtime, docs and the SDK.
  • Scott also already announced a new preview drop of ASP.NET MVC, which you can get from the ASP.NET 3.5 Extensions download page.
• Here some primarily "new" news from MIX:.
• I'm not sure which team owns it, but I'd say the biggest previously-unannounced news was SQL Server Data Services (aka SSDS), a "highly scalable, on-demand data storage and query processing utility services." In other words, SQL in the sky. There's a free beta sometime this month you can sign up for. Very cool, though no word on what it's going to cost. If you're interested in this, I'd keep an I on the Data Platform Insider blog.
• John Lam announces the Dynamic Silverlight extension that lets you run DLR languages on Silverlight. Given that they talked about this last year, I'm not sure it's really "news", but John provides lots of gory details so it made the cute. But are they really using "DSL" as the acronym for this? Guys, that acronym's already taken.
• Mary Jo Foley has a scoop on Silverlight for Nokia Symbian mobile phones.
• There's a new beta of Expression Studio 2 as well as a separate Expression Blend 2.5 preview for Silverlight 2. Soma has the details. This isn't really a surprise, but I hadn't seen any news on new versions of all the Expression Studio products.

Lunchtime Coffee 153

• p&p have published new versions of both the Web Service and Web Client Software Factories. Beyond support for VS08, I'm not sure what's new but that's worth the price of download (admittedly close to zero) right there. I assume these need the most recent release of the Guidance Automation Toolkit as well.
• W3C has published a new working draft of the Service Modeling Language. I'm really interested to see where this technology goes.
• Yesterday, Microsoft announced the Silverlight Blueprint for Sharepoint, part of a larger Software + Services Blueprints initiative that I wasn't aware of. According to Michael Lehman (who's blog I've been been remiss to read of late), S+S Blueprints has a bunch of other interesting projects including Video.Show and Outlook+Services.
• Martian Maly demonstrates how you can use DLR trees to build a statically typed add function. Literally, my very first thought after Martin presented DLR Trees @ Lang.NET was "I wonder if you could use that for static languages too?" I guess the answer is yes.
• It's been six months, and Scott Hanselman still isn't evil. Perhaps he could start turn his ASP.NET wiki into an evil ASP.NET wiki? Actually, I'm only linking to his post because I liked the way he described blogging as "I'm writing a book that will never end".

Morning Coffee 143

• I've been sick for three days, hence the lack of posting around here.
• As a Redskins fan, it's hard to root for any other NFC East team. On the other hand, it sure was easy to root against the Patriots. Congrats to the Giants on their Super Bowl victory. Favorite headline: 18 and uh-oh!
• Sounds like there's cause for optimism regarding the writer's strike. But is it already too late? Will the 9% drop in viewers ever come back? Personally, I think the studios have hastened their own irrelevance.
• With last night's win, the Caps are one game above .500. In and of itself, that's nothing to be proud of - Coach Boudreau remarked when we reached .500 that the Caps had "officially reached mediocrity". However, the Caps are the only team in the SE conference that's above .500. If hockey used baseball standings, Carolina, Atlanta and Florida would each be 1/2 game back of the Caps. It's going to be a fight to the finish.
• In fairly big managed Ruby news, Wayne Kelly has decided to contribute to the IronRuby effort, effectively walking away from the Ruby.NET which helped get off the ground. One the one hand, obviously this is great for IronRuby. On the other hand, I liked the idea of multiple managed implementations of Ruby, so here's hoping Ruby.NET doesn't fade away.
• Speaking of the DLR, I know I mentioned Martin Maly's blog in my Lang.NET Morning Coffee Post, but I didn't actually get to read his posts on targeting the DLR until I unexpectedly had several days off sick. If you are at all interested in writing your own language for the .NET platform: Go. Read. Now. You should also check out Tomas Restrepo's blog, he has also started writing about targeting the DLR.
• Larry O'Brien's blog is currently offline, but he commented that he doubted my ToyScript F# parser would be more than 600 lines of code. Currently, the parser is clocking in at 287 lines of code plus about 50 more for the AST. It's not done yet - see earlier statement about being sick - but I'm fixing bugs not writing additional code at this point. To be completely accurate, that's 287 lines of FParsec code. It's taken me a little bit to learn FParsec, but so far I'm pretty happy with it.
• Scott Hanselman points to the new MS Deploy project, a tool for managing content and configuration on web servers. I've never understood why this wasn't a standard part of IIS. It seems every hosting company I've used has rolled their own web-based management tool like DotNetPanel.
• Oh yeah, Vista SP1 and Windows Server 2008 shipped Monday. Congrats!
• I fired up Inside Xbox the other day, and there was a page about the new Disney Channel show "Phineas and Ferb". Of course, with two kids under five, anything new on the Disney Channel is notable in my house. What made this blog-worthy is the fact that it's directed and written by Dan Povenmire, who I knew from my USC days. I used to go see his band Keep Left and groan loudly at the bad puns in their song "PSA". Dan, if you found this searching for yourself online: Awesome work, my kids love the show!

Morning Coffee 142 - Wishful Catchup Edition

• After spending most of the last four days away from my desk, I was planning on a quiet day to catch up on a variety of things. Then I heard the oh-so-minor news that Microsoft is offering to buy Yahoo for almost $45 billion. Hasn't been much reaction on the dev, architecture, politics and hockey-oriented blogs I read, but you can get a ton of reactions on TechMeme.
• Lost is back. Finally. I stayed up late last night reading Lostpedia, catching up on Lost Missing Pieces and the Find 815 ARG.
• Alex The Great had four goals and an assist in last night's victory. Coughing up three goal lead and letting the Canadiens tie the game in the last 30 seconds isn't encouraging, but a win is a win. The Caps are currently one game behind the SE leading Hurricanes and two games behind the current eight seed Rangers. Alex was named first star for January.
• Ted Neward has a nice summary of Lang.NET by day: one, two and three. I wonder if my talk qualifies for the exception to Ted's rule that "A blog is not a part of your presentation, and your presentation is not part of your blog". I had 15 minutes to discuss something I've written about over ten posts  (so far).
• John Lam points to the latest DLR hosting spec. I'm much more interested in the DLR code generator, but at least the hosting interface is documented.
• Scott Hanselman has a nice post on fluent interfaces. Note to self, find out if Beautiful Soup works with IronPython.
• I wonder if the VS Source Code Outliner PowerToy works with F#? (via Sam Gentile)
• Chris Tavares has an extensive post Deconstructing ObjectBuilder? I've poked around inside OB before, but I'm really looking forward to Unity (also via Sam Gentile)
• NVIDIA finally updated the drivers for the video card in my Tecra M4. That only took a year.

Morning Coffee 141 - Lang.NET '08 Edition

I was hoping to blog my thoughts on Lang.NET as the event went along. Obviously, that didn't happen, though I was pretty good about dumping links into my del.icio.us feed. The talks were all recorded, and should be up on the website in a week or two. Rather than provide a detailed summary of everything that happened, here are my highlights:

• The coolest thing about conferences like this is what John Rose called "N3" aka "Nerd-to-Nerd Networking". It was great to meet in person, drink with and geek out with folks who's blogs I read like Tomas Petricek, Wesner Moise and Larry O'Brien. Plus, I got to meet a bunch of other cool folks like Gilad Bracha, Stefan Wenig and Wez Furlong. That's worth the price of admission (which was admittedly nothing) right there.
• Coolest MSFT talk: Martin Maly "Targeting DLR". I was wholly unaware that the DLR includes an entire compiler back end. Martin summarized the idea of DLR trees on his blog, but the short version is "you parse the language, DLR generates the code". That's pretty cool, and should dramatically lower the bar for language development. Of course, I want to write my parser in F#, so I'm going to port the DLR ToyScript sample to F#.
• Runner-up, Coolest MSFT talk: Erik Meijer "Democratizing the Cloud with Volta". Erik is a great speaker and he really set the tone of his session with the comment "Division by zero is the goal, not an error". He was referring to an idea from The Change Function that user's measure of success is a function of perceived crisis divided by perceived pain of adoption. Erik wants to drive that adoption pain to zero. It's a laudable goal, but I remain unconvinced on Volta.
• Coolest Non-MSFT talk: Gilad Bracha "Newspeak". Newspeak is a new language from one of the co-authors of Java. It's heavily smalltalk influenced, and runs on Squeak. He showed developing PEGs in Newspeak, and they were very compact and easy to read, easier even than F#. He calls them Executable grammar, and you can read his research paper or review his slides on the topic. Unfortunately, Newspeak isn't generally available at this time.
• Runner-up, Coolest Non-MSFT talk: Miguel de Icaza "Moonlight and Mono". The talk was kinda all-over-the-place, but It's great to see how far Mono has come. Second Life just started beta testing a Mono-based script runner for their LSL language (apparently, Mono breaks many LSL scripts because it runs them so fast). He also showed off Unity, a 3D game development tool, also running on Mono.
• Resolver One is a product that bridges the gap between spreadsheets and applications, entirely written in IronPython (around 30,000 lines of app code and 110,000 lines of test code, all in IPy). Creating a spread-sheet based app development environment is one of those ideas that seems obvious in retrospect, at least to me. If you do any kind of complicated spreadsheet based analysis, you should check out their product.
• If you're a PowerShell user, you should check out PowerShell+. It's a free console environment designed for PowerShell and a damn sight better than CMD.exe. If you're not a PowerShell user, what the heck is wrong with you?
• Other projects to take a deeper look at: C# Mixins and Cobra Language.
• I thought my talk went pretty well. It's was a 15 minute version of my Practical Parsing in F# series. Several folks were surprised I've been coding F# for less than a year.