Log in

No account? Create an account

Thu, Aug. 20th, 2009, 03:23 pm
A few interesting tidbits about IronPython CodePlex releases

*written about a month ago*


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.

Sun, Aug. 16th, 2009, 10:18 am
Skydrive Needs Work

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.

Mon, Aug. 10th, 2009, 04:42 pm
When trivial CPython snippets don't work...

...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.

Thu, Jul. 23rd, 2009, 12:14 pm
Python 2.5 Reference Card


Applicable to IronPython 2.0.2 and largely relevant to IronPython 2.6.

Thu, Jul. 23rd, 2009, 11:14 am
Good interpersonal relationship advice

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.

Thu, Jul. 23rd, 2009, 09:49 am
IronPython 2.6 Beta 2 Released!


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.

Wed, Jul. 22nd, 2009, 08:31 am
IronPython 2.0.2 Released


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.

Wed, Jul. 8th, 2009, 10:36 am
North Carolina State's Computer Science Department

Anyone have strong opinions on the computer science program at North Carolina State University?  They seem to have a distance education program for a Masters of Computer Science degree - see www.csc.ncsu.edu/academics/graduate/degrees/mcsdl.php.  Awfully tempting given their (relatively) low tuition rate and Microsoft's tuition reimbursement program...

Also, does anyone know of any other major universities with a MSCS distance education program?

Fri, Jun. 26th, 2009, 08:58 am
And now for something completely different

I believe I'm not really allowed to comment on the European Commission complaining that Microsoft is unbundling Internet Explorer from Windows 7 in the EU, so I'll comment on something else entirely...  It goes without saying that the opinions expressed here are entirely my own.

Seeing as Toyota is now the world leader in automobile sales, I'd like to see the US Federal Trade Commission file an anti-trust suit against them for the unfair bundling of GPS units in their cars.  You see...due to these GPS's being physically attached to the interior of the vehicle I'm hurt as a consumer because:
  • I can't install a portable unit from a different GPS manufacturer inside the vehicle.  Err...now that I think about it the portable units install on the windshield or the dash and get powered by cigarette lighter outlets so this is not actually an issue
  • The vehicle doesn't come with a map of local electronics stores where I could buy my own portable GPS unit.  Oh...now that I think about it I Toyota's built-in GPS unit will actually HELP me to find these stores selling competing GPS units.  Darn again
  • My car insurance won't cover the theft of Toyota's GPS unit because it's physically attached to the vehicle.  No, wait...that's not right either.  It's the other way around which actually provides a huge benefit to me
  • Ten years ago no cars came with GPS units pre-installed on them and I don't want to pay whatever extra money Toyota is adding to the base vehicle price to cover this GPS.  On that note, I don't want to pay for the heater or useless things like seat belts and parking brakes either
Hopefully you realize the absurdities above are intended as pure sarcasm.  My wife and I love the Toyota Rav4 we bought a couple years ago and WISH they bundled all Rav4s with GPS units.  Maybe if they did our car wouldn't have been broken into for the portable unit last year.

Tue, Jun. 23rd, 2009, 12:07 pm
IronPython 2.6 Startup Time Now 34% Faster Under x64

The performance numbers called out below were obtained using Ngen'ed IronPython/DLR assemblies with CPython's stdlib in sys.path.  It goes without saying that your (performance) mileage will vary greatly depending on your machine setup.

PS C:\SnapTempi> type hw.py
print "Hello World"

PS C:\SnapTemp> (measure-command {&"C:\Program Files (x86)\IronPython 2.6\ipy.exe" hw.py}).TotalSeconds

PS C:\SnapTemp\> (measure-command {&"C:\Program Files (x86)\IronPython 2.6\ipy64.exe" hw.py}).TotalSeconds
Allow me to elaborate on this perf gain...Dino made a change recently such that ipy.exe is now strictly a 32-bit only assembly.  That is, it gets executed as a 32-bit CLR process on both x86 and x64 operating systems.  ipy64.exe, despite what its name might imply, is a platform agnostic assembly matching the old behavior of ipy.exe in the sense that it gets executed as a 32-bit process on 32-bit OSes and 64-bit on 64-bit OSes.  At least part of the perf gain here comes from the fact that my simple Hello World program is most definitely not consuming anywhere near 4 gigs of memory, and overall memory consumption goes up for 64-bit processes => remember the size of pointers gets doubled.  Just checked and the physical memory working set of ipy.exe was 31K compared to 44K under ipy64.exe for the Hello World program.  This ~30% difference in memory consumption helps explain why we get better perf under ipy.exe.

Wed, Jun. 17th, 2009, 10:03 pm
Python Support in Visual Studio

Every couple of months we see a bug report on IronPython Studio or someone on the IronPython Mailing List asking why Microsoft doesn’t support Python in Visual Studio.  Most recently there was a pretty lengthy thread about Python intellisense in VS – see http://lists.ironpython.com/pipermail/users-ironpython.com/2009-June/010566.html.  I’ll attempt to shed more light on some facts mentioned in the thread…

A long time ago (2005), in a galaxy far, far away (Microsoft’s building 42) at least one Jedi (aka software engineer) used the Visual Studio Force to put together a Python light saber…err…I mean ‘language service’ for Visual Studio 2005 – see http://lists.ironpython.com/pipermail/users-ironpython.com/2005-December/001375.html for background.  A ‘language service’ is simply an extension to Visual Studio that makes it aware of one or more file extensions denoting a programming language Visual Studio doesn’t understand by default.  Among other things, this means Visual Studio might provide syntax highlighting for the programming language in the editor.  Any ways, this particular Python language service was never intended to provide complete IronPython support for Visual Studio.  Instead, this was bundled with the VS 2005 SDK as a complete sample to show developers how to extend Visual Studio for their own programming languages.  I’m not even sure any testers on the IronPython team ever evaluated this sample, but do believe we had at least one developer working on it.  I can’t really provide too many more details on the Python language service in the VS 2005 SDK as I didn’t join the IronPython team until summer 2006.

IronPython Studio was an update to the VS 2005 SDK Python language service for VS 2008 put together by a consulting firm named Clarius Consulting Labs.  To the best of my knowledge the IronPython Team had no involvement in the creation of IronPython Studio.  Also, the emphasis again was on being a complete VS language service implementation and not necessarily adding the best Python support to VS.  I think it’s a little unfortunate this tool has ‘IronPython’ in the title as this confuses people and leads them to believe we have the ability to fix bugs in it and also add new features (none of the IronPython Team is even listed as contributors to IronPython Studio – see http://ironpythonstudio.codeplex.com/People/ProjectPeople.aspx).  Finally, a few people in the IronPython community have observed that this piece of software is “abandonware”.  I agree, but wouldn’t be too surprised if it got revived for VS2010.

I think I speak for everyone on the IronPython Team when I say we’d love to see IronPython support in Visual Studio by default without the need for any language service addition.  The thing is these types of decisions are made at a much higher level than us and are heavily influenced by business needs.  What I’m getting at here is if enough people provided feedback via the proper channels that:

  • The next version of VS is great, but it’d be better if it supported Python development
  • You don’t currently use VS but you would if it had Python support
  • Ahem…you’d be willing to pay for IronPython support in VS
  • Etc

then the next version of VS could very well have Python support built into itJ  What are the proper channels for feedback you ask?  The VS 2010 feedback page (https://connect.microsoft.com/VisualStudio/content/content.aspx?ContentID=9790) would be a great start.

Wed, Jun. 17th, 2009, 07:40 pm
Congratulations to the Jython Team

Looks like the Jython guys just released 2.5.0 final!  I'm curious as to which version of CPython they target next compatibility wise...

skipped back 12