- Ted Newards Summary of the Day Two Proceedings
- The Paedantic Programmer Also Reports (but spends more time trying to package the DLR as a .deb)
- eWeek Reports on Resolver One - the spreadsheet that empowers users!
- DotNetLanguages Summarises Todays Speakers
Wednesday, January 30, 2008
Giles Thomas and Resolver One at Lang.NET Day 2
Giles Thomas demoed and explained Resolver One as part of the second day of the Lang.NET 2008 Symposium. Seo Sanghyeon talked about retargeting the DLR for fun and profit (presumably as part of his work for Mozilla on IronMonkey).
Labels:
conference,
resolver
Global System Builder
Global System Builder (GSB) is a light-weight Integrated Development Environment (IDE) designed to provide software developers with the capability to dynamically program software in real-time from anywhere to anywhere in the world over the internet using a web browser.
This seems to be the fruition of a Web Based IDE for Distributed Programming in IronPython, last blogged about in June 2007.
This is an open source project (codeplex home page), and the web IDE includes an interactive IronPython interpreter and live object browser!
This seems to be the fruition of a Web Based IDE for Distributed Programming in IronPython, last blogged about in June 2007.
This is an open source project (codeplex home page), and the web IDE includes an interactive IronPython interpreter and live object browser!
IronPython 2.0 Alpha 8 Release
IronPython 2.0 Alpha 8 has been released.
As well as closing about forty issues, the release includes the following notes:
We have just released IronPython 2.0 Alpha 8. Aside from the usual bugs fixes this release includes a fairly major change. This is the first release of IronPython where the Visual Studio solution file, IronPython.sln, is in Visual Studio 2008 (VS2008) format. This file is in fact incompatible with Visual Studio 2005 (VS2005) and the msbuild executable distributed with the .NET 2.0 SDK. If you currently build IronPython from VS2005 or the .NET 2.0 SDK this change will affect you and you have at least a couple of available options:
Another notable change is that all built-in Exception classes are now new-style classes. This improves our CPython 2.5 compatibility and we’re now able to run quite a few more CPython 2.5 tests successfully. On that note, a lot of effort has gone into making IronPython pass more of CPython’s 2.5 tests.
As well as closing about forty issues, the release includes the following notes:
We have just released IronPython 2.0 Alpha 8. Aside from the usual bugs fixes this release includes a fairly major change. This is the first release of IronPython where the Visual Studio solution file, IronPython.sln, is in Visual Studio 2008 (VS2008) format. This file is in fact incompatible with Visual Studio 2005 (VS2005) and the msbuild executable distributed with the .NET 2.0 SDK. If you currently build IronPython from VS2005 or the .NET 2.0 SDK this change will affect you and you have at least a couple of available options:
- Upgrade to .NET 3.5 or VS2008. It’s important to point out that internally we pass the “/toolsversion:2.0” flag to msbuild when building from a command prompt. This isn’t mandatory though and the reason we use it is to ensure IronPython continues to run under .NET 2.0.
- Continue to build IronPython under VS2005 or the .NET 2.0 SDK using IronPython2005.sln. IronPython2005.sln is the VS2005 version of IronPython.sln and exists alongside IronPython.sln in the source distribution zip file. We do not recommend this however as IronPython2005.sln is deprecated and we don’t plan on updating it
Another notable change is that all built-in Exception classes are now new-style classes. This improves our CPython 2.5 compatibility and we’re now able to run quite a few more CPython 2.5 tests successfully. On that note, a lot of effort has gone into making IronPython pass more of CPython’s 2.5 tests.
Labels:
release
Tuesday, January 29, 2008
Quiz: Can you count how many combinations...
Mike Stall moves on from calculating army sizes with IronPython, and uses it to answer quiz puzzles...
Labels:
games
Lang.NET Symposium - Reports from Day 1
The Microsoft compiler conference, the 'Lang.NET Symposium' is in full swing. Yesterday Jim Hugunin wowed the crowds with his talk about IronPython whilst Martin Maly astonished with the DLR. Today Resolver's one Giles Thomas will be wowing them even more with Resolver One.
- Lang.NET 2008 Day 1 Thoughts - Charles Nutter, a JRuby core developer employed by Sun, reflects on day 1 and particularly the DLR.
- Highlights of the Lang.NET Symposium, Day 1 - A blog entry from Ted Neward describing all the presentations from yesterday.
- Lang.NET Symposium - A very brief report from Laurance A. Lee.
- From Lang.NET 2008 - Another report from an attendee impressed with the DLR, who is recording his notes on a wiki page.
Labels:
conference,
dlr,
languages
Sunday, January 27, 2008
IronPython 1.1.1 Released
IronPython 1.1.1 RC was recently released. After a couple of weeks with no reported problems, 1.1.1 this has become a full 1.1.1 release.
This release fixes more than twenty bugs reported against IronPython 1.1.
This release fixes more than twenty bugs reported against IronPython 1.1.
Labels:
release
Saturday, January 26, 2008
Web Seminar: Silverlight and ASP.NET in IronPython & IronRuby
Dr. Dobbs is hosting a Net seminar on dynamic languages in Silverlight and ASP.NET. The 60 minutes session (on Tuesday February 19th) is being run by Jimmy Schementi, a Microsoft program manager.
Labels:
asp,
dlr,
silverlight,
team
Friday, January 25, 2008
Help Wanted: IronPython PM
John Lam posts a job advert (Microsoft) for a program manager for IronPython. John compares the job to being a movie producer (hey it sounds great), and it is both a technical and evangelist role:
Labels:
team
Dynamic Lookup in C#
.NET languages are inexorably being influenced by dynamic languages like Python. Visual Basic Ten will include dynamic features, using the Dynamic Language Runtime. C# 3.0 has gained new features, like type inferencing and anonymous types, that bring some (but only some) of the benefits of dynamic languages to C#. This 'Future Focus' article starts to look at how the DLR, the interoperation of C# and dynamic languages, and directly dynamic behaviour will be further integrated into C# and Visual Studio in the future:
Thursday, January 24, 2008
CLR Inside Out - Dynamic Languages and Silverlight
Jimmy Schementi is another member of the DLR / IronPython team with a blog:
He has just written an article for the CLR Inside Out online magazine:
The article focuses on the DLR Console, a Python interactive interpreter that runs in Silverlight and allows you to mix working with XAML and other dynamic languages in the interpreter.
He has just written an article for the CLR Inside Out online magazine:
The article focuses on the DLR Console, a Python interactive interpreter that runs in Silverlight and allows you to mix working with XAML and other dynamic languages in the interpreter.
Labels:
dlr,
silverlight
Tuesday, January 22, 2008
Building a DLR Language - Dynamic Behaviours 3
Martin Maly continues his exploration of the Dynamic Language Runtime internals:
Labels:
dlr
Monday, January 21, 2008
ASP.NET - IronPython
ArtyProg posts an entry showing example code for ASP.NET used with the free Visual Web Developer Express Edition 2008.
Labels:
asp
Sunday, January 20, 2008
PyPy Goes .NET
At the recent PyPy Sprint they worked on the integration of 'pypy-cli' with the .NET framework. They are implementing a clr module that provides compatibility with the way IronPython (and also Python.NET) do things. You can now add references to assemblies and import (and use) .NET classes.
Automatic handling of delegates isn't implemented, so you can't yet use events. Like much of PyPy, it is very exciting and nearly useful...
Automatic handling of delegates isn't implemented, so you can't yet use events. Like much of PyPy, it is very exciting and nearly useful...
Labels:
pypy
Saturday, January 19, 2008
Martin Maly's New Blog on the Dynamic Language Runtime
Martin Maly, one of the IronPython core developers, has started a new blog. His first six entries all focus on the Dynamic Language Runtime, and go into the details of how it works and how to implement your own DLR language:
Labels:
dlr
Thursday, January 17, 2008
More IronPython Posts
There have been a few more IronPython related posts recently:
- Battle Simulation Part 3: Size vs Smarts - Mike Stall does it again
- Simple DLR Language - A simple calculator language implemented with the Dynamic Language Runtime
- IronPython in Action, ConfigObj and doctests - News on the latest and coming chapters of "IronPython in Action"
- Changing the Default Browser with IronPython - Monkeying with the registry to change the default browser from IronPython
- Chasing Memory Leaks in Python Applications - How a problem in the IronPython implementation caused a hard to trace memory leak in Resolver One
- Anti-Pattern: Static Subject to Observer Mapping - Kamil's explanation of the anti-pattern that caused the memory leak
C Extensions for IronPython
A while ago Resolver Systems announced an open source project to get Python C-extensions working with IronPython. The project has been quiet for a while, but now that that the Resolver One 1.0 release is out of the way we can devote more time to it.
Fortunately one of our developers (William Reade) went to India over Christmas and spent some time hacking on the beach. He made good progress and has got 'zlib.pyd' loaded from IronPython and can call into it. He has just posted code and an explanation.
There is still an enormous amount of work, but not only does the basic approach work - we have the framework of an implementation.
Fortunately one of our developers (William Reade) went to India over Christmas and spent some time hacking on the beach. He made good progress and has got 'zlib.pyd' loaded from IronPython and can call into it. He has just posted code and an explanation.
There is still an enormous amount of work, but not only does the basic approach work - we have the framework of an implementation.
Labels:
extensions,
resolver
Resolver 1.0 Released
After two years, two months and two days - we have finally released Resolver One 1.0. Resolver One is a spreadsheet application, fully programmable in IronPython, and is free for non-commercial uses.
Resolver One is the largest IronPython application to date, with around of 140 000 lines of IronPython code in production and the test suite.
Resolver One is the largest IronPython application to date, with around of 140 000 lines of IronPython code in production and the test suite.
Tuesday, January 15, 2008
IronPython 1.1.1 RC Released and DLR Hosting Spec
After a long hiatus there is a new release of IronPython 1.1: a release candidate of 1.1.1. If no problems are found this will shortly become 1.1.1.
The 1.1.1 release is a bugfix release, fixing around 20 bugs (most of which were already fixed in IronPython 2.0).
This is great news as IronPython 2.0 (the Dynamic Language Runtime based version) is still in alpha and a final release isn't expected until the end of the year. A lot of people (including Resolver Systems) are still using IronPython 1.1.
The hosting API for the DLR is still changing as it is adapted to better support multiple languages (especially IronRuby). The aim is to ship DLR 1.0 at the same time as IronPython 2.0 final (but that may not work out).
The goals for IronPython generally include CPython 2.5 compatibility and fully running on top of the DLR. There have already been numerous improvements from IronPython 1.1 -> 2.0 and there should be a bunch more random improvements (e.g. bug fixes, performance, etc…).
An updated DLR API hosting spec document was recently made available:
Not all of the functionality in the spec is avilable in the current release of the DLR (part of IronPython 2.0 Alpha 7).
The current status is that ScriptEngine, ScriptScope, ObjectOperations, and ScriptSource (but still named SourceUnit) are fully implemented – although there are certainly some bugs still lurking.
Current planning going forward is to work on replacing ScriptEnvironment w/ ScriptRuntime, switching to use MBRO objects instead of the interfaces used today (completing the remoting story), and other small tweaks. In February the team aim to be looking at finishing up the support for multiple engines in the same app domain, defining and implementing the full set of configuration/options, and general fit-and-finish work.
The 1.1.1 release is a bugfix release, fixing around 20 bugs (most of which were already fixed in IronPython 2.0).
This is great news as IronPython 2.0 (the Dynamic Language Runtime based version) is still in alpha and a final release isn't expected until the end of the year. A lot of people (including Resolver Systems) are still using IronPython 1.1.
The hosting API for the DLR is still changing as it is adapted to better support multiple languages (especially IronRuby). The aim is to ship DLR 1.0 at the same time as IronPython 2.0 final (but that may not work out).
The goals for IronPython generally include CPython 2.5 compatibility and fully running on top of the DLR. There have already been numerous improvements from IronPython 1.1 -> 2.0 and there should be a bunch more random improvements (e.g. bug fixes, performance, etc…).
An updated DLR API hosting spec document was recently made available:
Not all of the functionality in the spec is avilable in the current release of the DLR (part of IronPython 2.0 Alpha 7).
The current status is that ScriptEngine, ScriptScope, ObjectOperations, and ScriptSource (but still named SourceUnit) are fully implemented – although there are certainly some bugs still lurking.
Current planning going forward is to work on replacing ScriptEnvironment w/ ScriptRuntime, switching to use MBRO objects instead of the interfaces used today (completing the remoting story), and other small tweaks. In February the team aim to be looking at finishing up the support for multiple engines in the same app domain, defining and implementing the full set of configuration/options, and general fit-and-finish work.
Saturday, January 12, 2008
Battle Simulations with IronPython (Part 2)
Mike Stall continues his exploration of modeling RTS battles with IronPython. More code and graphs!
Labels:
games
The Python Challenge - from Powershell!
Mark (The Powershell Guy), has been having fun with The Python Challenge. Several of the levels can be done straight from Powershell, but the latest one he has reached requires loading Python pickles. To solve this he uses the IronPython assemblies and the Python standard library, from Powershell of course:
In one post he mentions the Microsoft Winter Scripting Games, which are Feb 15th to March 3rd. Hopefully there will be some contenders using IronPython.
In one post he mentions the Microsoft Winter Scripting Games, which are Feb 15th to March 3rd. Hopefully there will be some contenders using IronPython.
Labels:
fun,
languages,
powershell
Thursday, January 10, 2008
UI Automation on the FePy Blog
Jim Hugunin recently posted an example of using the .NET 3.0 UI Automation API from IronPython. This library hasn't yet been implemented for Mono, so Seon Sanghyeon
has written two blog entries on using an equivalent, "Assistive Technology Service Provider Interface", with IronPython:
has written two blog entries on using an equivalent, "Assistive Technology Service Provider Interface", with IronPython:
Saturday, January 05, 2008
Python vs C# 3.0: Tuples vs. Anonymous Types (Redux)
Dare Obasanjo looks at idomatic language use, in both Python and the new features of C# 3:
Labels:
comparison
Friday, January 04, 2008
Reinforce It 1.1 Launched!
Martin Schray has just released Reinforce It v1.1. Written in a combination of C# and IronPython:
What is Reinforce It!? Its an application that sits in the system tray and flashes a reminder (via a toast window similar to Outlooks). The intervals between the reminders and the reminder message are configurable.
What is Reinforce It!? Its an application that sits in the system tray and flashes a reminder (via a toast window similar to Outlooks). The intervals between the reminders and the reminder message are configurable.
Labels:
project
Thursday, January 03, 2008
All Possible Font Styles
We've nearly completed a new feature in Resolver, supporting all the different font styles offered by the .NET font dialog.
At the moment the Text Formatting dialog - which uses the standard .NET font dialog - allows you to select bold, italic, underline, and strike-through: but Resolver only supported bold.
In implementing this Kamil needed access to all the possible font style combinations. Here is how he did it (and why):
At the moment the Text Formatting dialog - which uses the standard .NET font dialog - allows you to select bold, italic, underline, and strike-through: but Resolver only supported bold.
In implementing this Kamil needed access to all the possible font style combinations. Here is how he did it (and why):
Labels:
resolver
IronPython on eee PC and OLPC
I've just received my Asus eee PC (8GB/1GB). It's very nice, unbelievably cute. I would have bought an OLPC of course, but they won't ship to the UK...
Anyway, I have no reports on IronPython running on either of these devices. There are reports of Mono running on both though, and as Mono comes with IronPython it should be straightforward:
Those who don't believe that it is possible to create good looking desktop applications with Mono and its Windows Forms implementation need to check out Plastic SCM:
(Miguel has screenshots on the Mac and Linux.)
Oh, one final thing. Second Life offers a fantastic three dimensional virtual reality to explore. What is the obvious geek thing to do then? Build a text based interface for it of course! If this sparks your interest, then you may want to checkout 'SLTalker' and help write it in IronPython:
Anyway, I have no reports on IronPython running on either of these devices. There are reports of Mono running on both though, and as Mono comes with IronPython it should be straightforward:
Those who don't believe that it is possible to create good looking desktop applications with Mono and its Windows Forms implementation need to check out Plastic SCM:
(Miguel has screenshots on the Mac and Linux.)
Oh, one final thing. Second Life offers a fantastic three dimensional virtual reality to explore. What is the obvious geek thing to do then? Build a text based interface for it of course! If this sparks your interest, then you may want to checkout 'SLTalker' and help write it in IronPython:
Labels:
hardware,
mono,
secondlife,
winforms
Wednesday, January 02, 2008
Get values from Wii Remote (through IronPython and WiimoteLib.dll)
This is an English translation of the Japanese blog entry I linked to last week on using the managed Wii remote interface from IronPython:
Labels:
games
Age of Empires Battle simulation with IronPython
Mike Stall has been using IronPython to simulate Age of Empires archer battles. Discussion, code and charts!
Labels:
games
Does C# 3.0 Beat Dynamic Languages at their Own Game?
Dare Obasanjo continues his exploration of IronPython by exploring it to C# 3:
C# 3 has several new features, that even if not directly inspired by Python, will seem very familiar to Python programmers...
Dare concludes:
I love the REPL, I love the flexibility that comes from having natural support tuples in the language and I love the more compact syntax. I guess I’ll be doing a lot more coding in Python in 2008.
C# 3 has several new features, that even if not directly inspired by Python, will seem very familiar to Python programmers...
Dare concludes:
I love the REPL, I love the flexibility that comes from having natural support tuples in the language and I love the more compact syntax. I guess I’ll be doing a lot more coding in Python in 2008.
Labels:
comparison,
csharp
Subscribe to:
Posts (Atom)