A Good Mix 21: 3D Modelling, WMI, and IronPython Startup

Another collection of blog entries and articles related to IronPython and the Dynamic Language Runtime.

• Scripting (IronPython) exposing Naro document API

IronPython was integrated for some time to NaroCAD. But in fact it has two problems:

• It was not able to access NaroCAD shapes or anything from NaroCAD so it was not powerful enough to do something useful, excluding you did want to make a processing task using python
• IronPython implementation (and python in itself) do not work with Generics. So even you had access to Naro's document model, the Naro's extensible model was not accessible to IronPython script programmers.

This is why it was used lazy loading of IronPython as it does useless slowdown on startup of NaroCAD.

Right now both are addressed, exposing to you a document reference that you can create from it using a PyNodeUtil class a shape node. This is fairly important achievement as it can make easier without recompile NaroCAD to migrate your shapes if you can expose to IronPython a non generic class with your shapes.

• IronRuby and IronPython--What Dynamic Languages Have Wrought
  

A very brief article on .NET dynamic languages (IronPython and IronRuby) from the University of Texas at San Antonio Institute for Cyber Security:

Earlier this week, version 0.9 of IronRuby was released, the last beta before the final 1.0 version. About two weeks before that, the IronPython project released its feature complete 2.6 beta of the most widely used version of Python. The "iron" prefix implies that these languages are meant to execute on the .NET runtime and interoperate with the .NET framework and classes.

• Access System Time Remotely using Iron Python

A short snippet of code using Windows Management Instrumentation (WMI) to access the system time of a remote computer.

• A little more IronPython

Another newcomer to IronPython. In this blog entry Farid Zakaria explains some of the fun he has been having and then goes on to look at a few different IDE / editors for working with IronPython.

Working my way very slowly through IronPython in Action, and so far it is pretty neat. Probably the craziest thing is building a GUI application using the interactive console. However in order to get the most of out that joy, the interactive console must be placed on a separate thread. Normally it is on the same thread as the GUI thread causing it to lock up since the Form is in a continous loop.

The IronPython distribution provides a sample script winforms.py. Winforms specifically places the console on a separate thread to play around with the GUI interactively. With winforms imported, you can display the form by calling form.Show () rather than Application.Run (form).

Making changes to the GUI during runtime makes me smile.

• Pre-compile the parts of CPython standard library IronPython uses to make its startup time faster
• Either empty site.py or -S option helps a lot with IronPython startup time ~ 4 times faster, thanks to @voidspace!
  

These aren't so much blog entries as they are interesting titles... In the first Mikhael Plavskiy complains that just because IronPython does a lot on startup (imports site.py) that's no excuse for it taking a long time. I suggested that he tries with an empty site.py, or as he points out the -S command line switch, and suddenly IronPython starts up four times faster! IronPython startup improves in IronPython 2.6, but skipping the importing site step still has a big benefit.