Horror Stories for Halloween

Halloween is the time for scary movies. Julie and I have seen two since I got back from OOPSLA – 28 Days Later… and The Grudge. I’m not sure I would have called 28 Days Later “Scary As Hell” but I did really like it. It had a real plot and real characters that had real arcs. True, it also had zombies running around, but that was much less the focus than I expected. In fact, I think it had some thinly veiled social commentary (that I can’t discuss w/o spoiling the movie).

On the other hand, The Grudge is simply a run-of-the-mill haunted house story. Not that scary and no plot or characters worth mentioning. Simply a series of loosely strung together scary scenes with little consistency. Which was a bummer as it did have a great opening scene. After all the comparisons to The Ring (which I liked, though not as much as most people) and the fact that Sam Raimi was producing, it was very dissappointing.

Of course, neither of these can compare to the potential horrors of election fraud on Tuesday. Apparently, over 80 lawsuits have already been filed (on both sides) which I don’t take as a good sign.

Photo Story 3

Since I’m at OOPSLA, I’m behind on my blog reading. But in case someone else hasn’t already blogged it, go check out Photo Story 3. I’ve got an an 20 month old, over 2000 pictures taken this year and a pile of relatives who are clamoring regularly for pictures so I’m pretty excited about this.

Other MSFT Bloggers at OOPSLA

Some other ‘softies blogging OOPSLA:

  • Keith Short talks about the DSL Tutorial and apologizes for our keynote demo.
  • Steve Cook talks about the MDA panel and says the keynote demo “wasn’t such a great idea”
  • Stuart Kent describes the DSL Toolkit and calls the keynote demo a “commercial break”
  • Michael Lehman briefly describes his work building a software factory for the DSL Tutorial and blogs Jack’s GPCE keynote presentation on Software Factories

Finally, Brant Carter took me to task for pointing out that Alan Kay ended his Turing Lecture with a product demo. Brant makes good points and I agree with all him. I think all the ‘softies blogging OOPSLA have acknowledged how poorly this went and I certainly didn’t mean to imply that somehow we were vindicated by Alan’s demoing stuff in his lecture. I plan on giving Squeak a deep look when I get some free time – I have an 18 month old son so Alan’s lecture on teaching computer science resonated with me.

Building DSLs in VS

Last night, after the Turing Lecture, we hosted a FlashBoF on “DSL’s in Visual Studio”. Stuart answered a bunch of questions and gave a much more detailed demonstration of the new DSL Toolkit than we could show during the keynote. Here’s what I learned from the session:

  • Models are stored in XML files. The language designer outputs an object model and will eventually also output an XSD. For example, here’s a screenshot of the language designer from the DSL Toolkit we’re releasing. Inside the designer, I’ve got a sample UIP DSL (I hacked this up on my own, this is not exactly the same one we demoed yesterday). As you can see, there’s a PageCollection concept which contains Page concepts that have Name and Kind values. Page concepts also has a collection of Transfer concepts, which in turn have Label values. Generating an object model makes it easier to write tools that manipulate models. Typically, I’m anti-XML-Serialization but in this case – where we have a relative simple XSD – it works fine. I could also manipulate the model by accessing the underlying XML if I want to.
  • Code generation uses templates and looks a lot like CodeSmith or old-school ASP. You interleave the static elements of the generated code with blocks of code that access the model (via the object model described above) and generate the dynamic model-specific elements of the code. So I’m guessing that people using the codegen tools like CodeSmith will feel right at home with this toolkit.
  • In the current builds (which is to say later than the build that we’re releasing first – the first build doesn’t include any of the code generation support) we’re generating a single code file from a model. Eventually we’ll be able to manipulate multiple files from a single model. This is similar to how the Class Diagram works – add a new class onto the diagram and a new file gets added to the project, delete the class from the diagram and the file gets removed from the solution.
  • Not all models are used to generate code. For example, in VSTS the Logical Data Center and Virtual Deployment models don’t generate code. They are useful  because I can use them to validate the Distributed System Model which does generate code.
  • Someone asked about the implications of code coverage, profiling and test-driven development on a DSL-based process. Frankly, I don’t know but it certainly got me thinking. The general consensus was that we’re still in the bootstrap phase of making DSL-based development a reality and these are issues we’ll have to deal with as we move forward.

And Now For Something Completely Different

We interupt this blog’s coverage of OOPSLA with a quick observation & question related to development…

I’m hacking around writing a Word 2003 SmartTag in C# (more on the why later). I wanted my recognizer to be document-dependent – i.e. depending on some custom document properties, I wanted to change what gets recognized. A little digging reveils that there is no way (that I could find) to access the Word object model from the recognizer! The Recognize (and Recognize2) method receives strings as parameters, but it doesn’t receive an app-specific target object. This is unlike the Smart Tag Action‘s InvokeVerb (and InvokeVerb2) method which receives a Range object (from which you can navigate to the containing document, application and window) when running inside of Word. Bummer.

I think the reason for this is that the recognizer appears to run on a background thread while the action appears to run on the main app thread. Furthermore, both threads are STA apartment threaded, so if I can access the COM-based object model from the action thread, I can’t access it directly from the recognizer thread. I actually hacked up an add-in to provide the ActiveDocument to the recognizer thru a backchannel and it hangs Word on shutdown. I thought there might be an issue releasing the COM reference, but explicitly releasing it crashes the recognizer the next time it accesses the ActiveDocument.

So I’ve come to the conclusion that I somehow need to marshal this call from the background thread to the main app thread the action and addin are runing on (I did verify that both of those run on the same thread). The question is, what’s the best way to do that given that I’m writing this in C#? I thought I might use a system similar to Windows Form’s Control.Invoke(…), but it turns out that works by sending windows messages which isn’t particularly feasible for my problem. So now I’m thinking I have pass the ActiveDocument reference to the background thread using CoMarshalInterface. Or I might be able to use RemotingServices.Marshal() instead.

Anyone have any ideas? If so, leave a comment or drop me a line.