http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=36150

This release contains a few small Silverlight fixes, with basically zero changes to the Desktop version of IronPython. Hopefully third time's a charm.

http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=34451

Well assuming no major problems are found this release, I should in theory have some time for more IronPython blog entries in about a month.  Let's see what happens...

We've heard from a few people in the last week that they're having trouble uninstalling our community technology preview of IronPython running under .NET 4.0 Beta 1 if the installation of .NET 4.0 Beta 1 has been removed or replaced in some fashion.  Basically what's going on is that a prerequisite for running IronPython.msi (whether you intend on installing/repairing/removing it) is the presence of a very specific version of .NET - namely v4.0.20506.  The tie in to this .NET 4.0 release means that even with an install of .NET 4.0 Beta 2, you'll be unable to remove the IronPython CTP for Beta 1 cleanly unless you also have .NET 4.0 Beta 1 installed concurrently (is this even possible I wonder...).

There's at least one alternative to removing "IronPython 2.6 CTP for .NET 4.0 Beta 1" if you no longer have access to .NET 4.0 Beta 1 on your machine.  Basically you'll just need to remove the related installation directory and shortcut menus by hand.  Also, there's those pesky registry entries that don't have to be removed, but can be if you prefer. 

Disclaimer
While the info presented below on removing "IronPython 2.6 CTP for .NET 4.0 Beta 1" without using the uninstaller from the Control Panel should work on just about anybody's machine, the steps were tested on a single 32-bit Windows 7 machine.  There's at least a trillion ways your machine(s) may vary from the test box, and not only may some steps not work...they could even hurt your machine!  Proceed with caution...

Step 1 - Remove the Installation Directory
Assuming you accepted the default installation directory for the CTP, you'll have either "%ProgramFiles%\IronPython 2.6 CTP for .NET 4.0 Beta 1" or "%ProgramFiles% (x86)\IronPython 2.6 CTP for .NET 4.0 Beta 1".  Simply open a command prompt as an Administrator and remove this directory:
    rmdir /s /q "%ProgramFiles%\IronPython 2.6 CTP for .NET 4.0 Beta 1"

Step 2 - Remove the Shortcut Menu
The shortcuts to the CTP's ipy.exe should be in "%ProgramData%\Microsoft\Windows\Start Menu\Programs\IronPython 2.6 CTP for .NET 4.0 Beta 1".  Verify the presence of this directory, open a command prompt as an Administrator again, and remove the directory:
    rmdir /s /q "%ProgramData%\Microsoft\Windows\Start Menu\Programs\IronPython 2.6 CTP for .NET 4.0 Beta 1"

Step 3 - "Fix" the registry
Background: as of today no IronPython release uses *any* information found in the registry.  There's .NET key/value pairs that could affect the runtime behavior of IronPython (e.g., NGen'ing), but these are not directly utilized by IronPython.  In effect, the only reason to follow this step is to remove "IronPython 2.6 CTP for .NET 4.0 Beta 1" as an option from the "Add/Remove Programs" portion of the Control Panel.  While the previous steps have very little chance of screwing up your machine, most people know that messing with the registry can cripple your box if you're not careful.  If I haven't scared you off yet...

1. Run "regedit" from an elevated command prompt
2. Press Ctrl-F and do a search on "IronPython 2.6 CTP for .NET 4.0 Beta 1". Keep searching (via the F3 key) until you find something like Computer\HKEY_CLASSES_ROOT\Installer\Products\70089FC31E5E8B340817C3CA5F82E45D containing keys such as ProductName, Version, etc.  Remove the directory which contains these keys and "IronPython 2.6 CTP for .NET 4.0 Beta 1" will be uninstalled as far as the Control Panel is concerned
3. There are other keys in the registry with respect to the CTP Beta 1 release.  My guess is that these are perfectly harmless to remove, but I wouldn't advise removing them

While I've been waiting for a huge build to finish unzipping on a shiny new Windows 7 test machine, I've been looking over my own and other IronPython team members' blogs.  I've come to the conclusion that there are far more comments for posts not dealing with Python, and in many cases the IronPython posts aren't getting any comments at all.  The missing interaction isn't necessarily limited to technical posts either from what I've seen.

Is this because we're doing a great job at covering IronPython topic xyz or because xyz just isn't that interesting?  If it's the latter, what would you like to see more of and less of?

Looks like a talk/paper I gave on distributed object simulation frameworks at the ICALEPCS (The International Conference on Accelerator and Large Experimental Physics Control Systems) conference back in 2005 was cited in what appears to be a computer science dissertation.  Sweet

While it's still fresh on my mind, I'll share a bit of interesting info about IronPython releases. What will blow most peoples' minds is that on average it takes us about five full working days to produce and signoff on a release for CodePlex. For example, we started the release process for IronPython 2.6 Beta 2 on Friday morning and released it today. "Dave, when all you have to do is build the 'release' configuration of the sources already on CodePlex how can it possibly take this long?" you ask. Three words: testing and Microsoft bureaucracy…err I mean "Microsoft processes".

 

First lets talk about testing as this is my field. If you look at the source zip file (or TFS enlistment) for any given IronPython release, you'll notice well over a hundred Python files under the "Src\Tests" directory. There's actually far more than this as this doesn't include the plethora of tests we don't ship on CodePlex yet (e.g., 100s of Cpython tests). For simplicity's sake…we'll just say there's exactly 100 tests.   Well each of these tests are run against the digitally signed "release" binaries you find in IronPython MSI installations and also "debug" binaries that we build from the source zip file and never redistribute. In other words, we're now up 200 (2x100) individual invocations of IronPython, and the tests against "debug" binaries take longer to run of course. To complicate things further, each of these 100 tests gets run with four different sets of flags passed to ipy.exe. For example, we might run "ipy.exe test_str.py", "ipy.exe -X:Interpret test_str.py", "ipy -X:NoAdaptiveCompilation test_str.py", etc.   This puts us at 800 (4x2x100) individual IronPython test invocations. Now you're probably saying "800 isn't that many Dave", but I haven't mentioned the OS combinations we run the tests on yet which include: x86 XP, x86 2003, x64 2003, x86 Vista, and x64 Vista. Ouch…we're now at a staggering 4000 (5x4x2x100) IronPython invocations for only 100 tests. It normally takes around two to three days to run all these tests and another half a day to investigate the 100+ failures we see during test pass signoffs. Let's just call this three full days of testing as I didn't even call out manual testing on the release contents among other things.

 
Most people will be surprised to know that IronPython must adhere to many of the same Microsoft corporate policies as a product such as Office 2007. I won't divulge any real details on these policies, but will say the following:

• We must ensure there's no "profanity" in IronPython sources.  You'd be amazed to know what kind of every day terms are forbidden...
• All images distributed with IronPython need to be reviewed
• Full security test passes are sometimes needed
• Etc

Adhering to these policies and documenting said adherence is now largely automated and takes anywhere from an hour to a full day.

 

As for the remaining day spent on releases…well…I'll save that for another blog entry.

Two out of the last three times I've tried to access my Skydrive in the past two weeks I've been welcomed with a message stating "That item seems to be missing".  This really is one software as a service Microsoft must get right and have a very high up-time.  Disappointing.

...it's time to call it a day. 

I've spent way too much time today trying to get a simple _ssl sample to run under CPython to show how broken IronPython's _ssl.cs is.  First, I discovered that not only do CPython's tests not work (they're trying to connect to svn.python.org, port 443, which consistently times out); they seem to be disabled as well via test_support.is_resource_enabled('network').  If anyone has encountered the "TypeError: sslwrap() argument 1 must be _socket.socket, not _socketobject" above and knows how to workaround it, I'm all ears.

http://users.physik.fu-berlin.de/~goerz/blog/wp-content/uploads/2008/09/python_refcard.pdf

Applicable to IronPython 2.0.2 and largely relevant to IronPython 2.6.

This is a general summary of Dale Carnegie's "How to Win Friends and Influence People".  The book was published in the 1930s but is still completely applicable today.  My two cents is that anyone in a management type position should try to live by this:

Part One

Fundamental Techniques in Handling People

1. Don't criticize, condemn or complain.
2. Give honest and sincere appreciation.
3. Arouse in the other person an eager want.

---

Part Two

Six ways to make people like you

1. Become genuinely interested in other people.
2. Smile.
3. Remember that a person's name is to that person the sweetest and most important sound in any language.
4. Be a good listener. Encourage others to talk about themselves.
5. Talk in terms of the other person's interests.
6. Make the other person feel important - and do it sincerely.

---

Part Three

Win people to your way of thinking

1. The only way to get the best of an argument is to avoid it.
2. Show respect for the other person's opinions. Never say, "You're wrong."
3. If you are wrong, admit it quickly and emphatically.
4. Begin in a friendly way.
5. Get the other person saying "yes, yes" immediately.
6. Let the other person do a great deal of the talking.
7. Let the other person feel that the idea is his or hers.
8. Try honestly to see things from the other person's point of view.
9. Be sympathetic with the other person's ideas and desires.
10. Appeal to the nobler motives.
11. Dramatize your ideas.
12. Throw down a challenge.

---

Part Four

Be a Leader: How to Change People Without Giving Offense or Arousing Resentment

A leader's job often includes changing your people's attitudes and behavior. Some suggestions to accomplish this:

1. Begin with praise and honest appreciation.
2. Call attention to people's mistakes indirectly.
3. Talk about your own mistakes before criticizing the other person.
4. Ask questions instead of giving direct orders.
5. Let the other person save face.
6. Praise the slightest improvement and praise every improvement. Be "hearty in your approbation and lavish in your praise."
7. Give the other person a fine reputation to live up to.
8. Use encouragement. Make the fault seem easy to correct.
9. Make the other person happy about doing the thing you suggest.

http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=27350

Lots of improvements in this release.  Startup time on 64-bit OSes should be about 33% faster, the _ctypes module has been implemented, and the Python debugger module, pdb, works for basic scenarios.

http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=22981

This is a pretty typical patch release of IronPython as it just includes a few bug fixes, assembly version numbers are the same, etc.  The only other interesting thing to report is it's every so slightly slower than IronPython 2.0.1 (see http://ironpython.codeplex.com/Wiki/View.aspx?title=IP202VsCPy25Perf&referringTitle=Home and compare this to http://ironpython.codeplex.com/Wiki/View.aspx?title=IP201VsCPy25Perf&referringTitle=Home) which could very well be attributable to machine jitter.