I did a two session presentation at LA Code Camp today to talk about the C# 4.0 dynamic feature and the dynamic language runtime. The presentation materials could be downloaded here.
The zip file contains the source code of several demos that I did today:
- DynamicTest: A simple C# dynamic example.
- BoxUnbox: Example demonstrates the boxing/unboxing behavior of C# dynamic variables.
- PrivateMember: Example demonstrate that code in full-trust can access private member but it will throw exception when running in partial-trust. A partial-trust sandbox is used to simulate the partial-trust environment in the demo.
- MultipleDispatch: This example was from Curt Hagenlocher’s blog.
- MOR: This example demonstrates accessing unknown type or dynamic object using dynamic variable. The MOR means minimalist OR Mapper; it converts query results in anonymous types dynamically.
- TypeModel: This demo shows how to access static members of a unknown type using dynamic variable. The unknow type is wrapper in the TypeModel object which implements IDynamicMetaObjectProvider interface. The TypeModel class is extracted out of the DLR Symbl example.
- DLRTreeTest: This example demonstrate factorial function implemented using System.Linq.Expression (Microsoft.Script.AST in .NET 3.5 version of DLR).
Executing the dynamic code will bring in the type information at runtime. I think that I just need to enhance my callsite binder to capture some information and then I will be able to convert the code that flow through my binder much more accurately. Mostly likely the converted code should work correctly right away. So I will just give it a name called Execution Assisted Code Converter. I will try to put together a prototype if I get a little bit of time.
Note: There are refinements to the thought through discussions of this post below.
I just uploaded ASP Classic Compiler Build 0.5.5.34834 to http://www.codeplex.com/aspclassiccompiler.
In this release, I have:
- Setup the infrastructure to map from generated code back to the source code so that we can report the location accurately in asp files. With that, I will be able to provide debugging experience using either Visual Studio or another CLR debugger fairly soon.
- If a file has multiple syntax errors, chances are that we are able to report all the errors at once. In contrast, Asp Classic only reports one error at a time. That is because our parser attempts to recover from the error and continue parsing the file. This is also essential for intellisence support in VS integration that will come in the near future.
The next build will be in two weeks as I am preparing for my presentations at the LA Code Camp right after PDC. I have blocked two sessions to discuss the C# dynamic feature and the Dynamic Language Runtime. My first talk will be mainly on the C# dynamic feature and the second talk will be mainly on the Dynamic Language Runtime. Here are the abstract of the sessions:
It has been several years since I researched the logging and tracing solutions last time so I need a revisit. ASP.NET always had tracing that can be turned on at the page level through page directive or the application level through the web.config file. The trace output can be either appended to the end of a page and viewed via trace.axd. ASP.NET tracing is different to System.Diagnostic tracing. Fortunately, ASP.NET 2.0 or later allows integration between the two. Dino has an excellent article on this subject.
The ASP.NET tracing is most useful tracing events relating to page life cycle. For flexibility in filtering and sending trace data to different target, there are a few logging frameworks available, such as log4net, nlog and the Enterprise Library Logging Application Block. If an application can not be tied to a particular logging framework, then one can either use a common library, or roll your own.
In .net 2.0 or later, there is actually an enhancement to the static Trace class called TraceSource. TraceSource is quite flexible and it allows filter both on the writer side through TraceSwitch and on the listener side through listeners configuration and filter. For a comparison between TraceSource and other frameworks, see the discussion on stackoverflow. For projects that need to minimize external dependency, TraceSource is an excellent choice. The only limitation to the TraceSource solution is the availability of listeners. .net framework comes with the 10 listeners:
The KUADC project comes with 6 listeners:
SqlTraceListenerThere are a few other trace listeners such as TCPTraceListener and UDPTraceListener can be found on searching Google.
I have uploaded Silverlight sample that uses my VBScript.net compiler to http://www.codeplex.com/aspclassiccompiler. It is available under the source tag in change set 31328 or later.
I am not quite using the capabilities in Microsoft.Scripting.Silverlight yet. I want to take advantages of it when its document becomes available. For the time being, I created my own little host called VBScriptHost in the SilverlightApplication1 project.
I modified App.xaml.cs to create an instance of VBScriptHost and expose it. In MainPage.xaml.cs, I created a ScriptScope object. This is the object that I feed host variables to VBScript. I then parse this object to the Execute method of a CompiledCode object.
In the example, I passed MainPage itself with the variable name "page" to the VBScript. In order to expose the object hierachy of the MainPage, I have to expose MyButton using the x:FieldModifier="public" attribute; otherwise, it is an internal property and is hidden from the dynamic code. In future versions, I will modify my binder in an attempt to access the internal properties so that we do not have to change the access level of objects in the page.
As usually, it can be downloaded from the source tab of http://www.codeplex.com/aspclassiccompiler.
- This version is built with DLR 0.92. It is compatible with VS 2010 beta 2.
- We have resolved all API difference with Silverlight so that Silverlight build of our VBScript.net compiler is available for the first time. We will upload some samples in the next weekly release.
- All the binaries are consolidated into the bin folder.
Going forward, we will stay on DLR 0.92 for a while so that we have a stable build so fix the bugs in core features.