Tail call performance on x86

MSIL includes the tail. prefix to be used with call instructions (call, callvirt, calli), and also the specialized form jmp. The tail. prefix is a hint that the stack frame of the current method should be popped from the stack before transferring control to the target of the call. This is important for functional languages…

12

Saving a file to the local disk in Silverlight

All user code in Silverlight runs in a sandbox. Hence, for security reasons, there are no APIs to directly open local files from disk. However, there is a OpenFileDialog class which allows a Silverlight app to open files on disk. Human intervention is required to interact with the dialog box. This ensures that the user…

7

CLS compilation of IronPython

One of the common feature requests for IronPython is to support static compilation. While the feature looks like a no-brainer initially, it does have a few wrinkles when you look at the details. Here are the different forms that a related question might look like? Can I call IronPython code from C#? Can I statically…

5

OLE automation (IDispatch) support in IronPython

IronPython 1.X IronPython 1.X supported COM interop by building on top of the COM interop support built into the CLR. This relies on the use of interop assemblies for managed code to access COM objects. The interop assembly can be accessed in different ways: clr.AddReference(“interopAssembly”) – This is the preferred mechanism so that the interop…

4

IronPython cannot call AutomationElement.FromHandle

If you use IronPython to call AutomationElement.FromHandle, it will return null. This happens because FromHandle uses Assembly.GetCallingAssembly and expects to get a statically compiled assembly with references to the correct version of the UIAutomation libraries. However, since IronPython code gets compiled on the fly using Reflection.Emit and DynamicMethods, it confuses AutomationElement. This UIAutomation team knows…

4

Using IReflect to expose a type as IDispatch to COM

The CLR supports marshalling of objects that support the IReflect interface as IDispatch COM objects. Similarly, IExpando gets marshalled as IDispatchEx. Here is a sample of a managed type called ManagedIDispatch which is used from VBScript and used in a late-bound way. VBScript just deals with IDispatch, and under the hoods, the CLR routes the…

4

OLE Automation support ON in IronPython 2.0 Beta 4

As I had mentioned in a previous post, we have added support in IronPython for accessing OLE Automation objects using the IDispatch interface, without having to rely on interop assemblies. This was enabled with the “ipy.exe -X:PreferComDispatch” command-line until IronPython 2.0 Beta 3. In Beta 4, this behaviour is on by default. This makes IronPython’s…

3

Proposed spec for Ruby’s Thread.critical=

Ruby has green threads, and so its implementation of Thread.critical= is speced as follows: Sets the status of the global “thread critical’’ condition and returns it. When set to true, prohibits scheduling of any existing thread. Does not block new threads from being created and run. Certain thread operations (such as stopping or killing a…

2

Accessing IronPython objects from native JScript (using IReflect)

The DLR aims to enable dynamic languages like IronPython and IronRuby to access and minipulate objects created by each other. But what about dynamic languages like JScript implemented using unmanaged code? It is sometimes useful for IronPython and native JScript to interact with each other. Consider the following scenarios: IronPython could be used to host…

1

Signals on Windows

While looking at signal support in IronRuby, I played with the signal and raise functions that are available in the C runtime. It turns out that these functions are much more limited than their Unix counterparts. On Unix, kill can be used to send a signal to another process, enabling cross-process communication. However, the CRT…

1