IronPython 2.6 Release Candidate 1 out of the door you might think that IronPython 2.0 was already defunct. Not true! David DiCato, an IronPython core developer, just posted to the IronPython mailing list asking what bugs people would like to see fixed in a 2.0.3 release:
As we work towards our IronPython 2.0.3 bugfix release, Dino and I would like to get a feel for which bugs left unresolved in 2.0.2 are most important for us to fix in the next release. Please let us know ASAP if there’s an issue you’d like to see fixed in IronPython 2.0.3. Thanks!PyDev) to his will for IronPython development. Google translate reveals his conclusion:
From now on you is CodeCompletition and much more are available. Separate assemblies that are not from the framework can use Project-> Properties-> PyDev - PYTHONPATH be added. A good overview of PyDev functionality can be found on the homepage under PyDev Features.
I hope Micorosoft not slept through it and gets with Visual Studio as IDE for IronPython back the crown. As so often has once again come to show someone from the Open Source camp and how it works. The funny thing is that it happens even at this time Microsoft's own open source project, which also holds in more formal entry into the framework. JAVA strikes back ;-)
The code is used by SeeMe, an open source Python application for Windows and Linux.
Chris Burrows is Microsoft developer who has blogged extensively about the new dynamic keyword in C# 4. dynamic is a mechanism for dynamic typing (and duck typing) in C# made possible by the Dynamic Language Runtime. Introducing dynamic elements into a static type system is not without its complexities and Chris does a great job of going through the implications and details.
In his latest blog entry on the subject Chris discusses using dynamic with type constraints:
You cannot specify type parameter constraints that involve dynamic. There are a few reasons why we disallow this. The first reason (and possibly the least satisfying) is that we have nowhere good to put the metadata that says the List<object> in question is really a List<dynamic>. Well, not without concocting some scheme to associate the DynamicAttribute with constraints that appear on methods and classes.If you are interested in using dynamic in C# then Chris' blog will be a useful resource. If you program in a dynamically typed language then you can just marvel at all the complexity you are saved from.
Math.NET is an open source mathematical toolkit written in C# for .NET and Mono:
Math.NET aims to provide a self-contained clean framework for both numerical scientific and symbolic algebraic computations. The project is covered under the GPL or LGPL, vary among various components.
Iridium is the numerical foundation of Math.NET, aiming to provide commonly used mathematical elements for scientific numerical computations. It offers the infrastructure for linear algebra, random generators and distribution, special functions, FFT and more.The codeplex project IronPythonMathNet is a reference document (with examples) for using MathNet.Iridium from IronPython.
We’ve been giving a lot of thought to our choice in Programming Language for Journey of Souls. For a while, it was starting to look like we were going to end up writing everything in PHP or Python. I think we’ve made our decision (or at least are very close). It ended up coming down to a few things that PHP and Python just don’t have any out of the box support for. Things that it would be extremely stupid for us to roll our own implementations, when another language offers the feature up really well. The first of these being Events and Event Handling. The second being a way to write game scripts in a way that they can be replaced on the fly while the game is still running. Here’s some of the details from our research and decisions.
That solved one of our two problems, but C# is a compiled language. If we need to make changes to the game, that’s going to require a recompiling and stopping the game to drop in the new binaries and … wait a minute. I remembered the DLR. Not only did I remember the DLR, I remembered that the languages (IronPython, specifically) can be embedded. Meaning, we can do our scripting for the game in IronPython, and it offers us up the opportunity to do nifty things like reload game scripts at runtime. This is absolutely amazing because it minimizes downtime for the game, in the long run, and allows us to immediately add new features and such to the game without a restart. It also still lets us do a lot of stuff in one of our preferred languages, while still being able to utilize C# for any heavy lifting that needs to be done.
In my mind, this seems like a very win-win scenario. We’re going to be future-looking, so I’ve already been considering the use of things like C# 4.0’s dynamic keyword for making interacting with IronPython that much easier. It also helps that I’ve already been using the Visual Studio 2010 and .NET 4.0 Betas. We still have a long way to go before we get something usable, but locking down our language choice is a huge milestone and an issue that’s been bothering us for a long time now. With that gorilla off of our back, we can start working more on the actual design of the game and how we want the core pieces to interact, knowing that we have an Event model that’s built-in to the language we’ll be developing in.
I’ll keep the updates coming as we have more things to share.