wxPython 2.8.7.1

I've just released the new 2.8.7.1 build of wxPython. This release has had some bugs fixed, some minor patches applied, and also incorporates the Google Summer of Code 2007 version of XRCed, and adds the Editra source code editor. More details can be found in the changes list. wxPython source and binaries for Windows, Mac OS X and Fedora can be downloaded from the download page. Binaries for Debian and Ubuntu i386 and amd64 architectures are available in the wxWidgets APT repository, see this wiki page for details.

NOTE: On Mac OS X 10.5 (Leopard) the Python 2.5 binaries of wxPython expect to be used with the user-installed version of MacPython, not the Apple installed version. A fix for this issue is being worked on for the next release. In the meantime you can either install MacPython 2.5.1 and adjust your paths so that that Python is used, or you can stick with Apple's Python and the wxPython 2.8.4.0 that comes with Leopard.

Happy Hacking!

Po-tay-toe, Po-tah-toe

Last week on wxPython-users a user wrote about a particular GUI class and said that, "it looks really awful." Trying to get more details from the person about what is so bad about it only resulted in some confusion because he seems to really like the class and listed some nice features when asked, "in what way is it awful?" Well, as you can probably guess, it turns out that English is not his native language and he intended to say that the GUI class in question filled him with awe, or in other words, that it is "really awesome."

This got me to thinking about something that has probably crossed every computer scientist's mind at one time or another: It's too bad that our spoken and written word can't be passed through something like a syntax check, preprocessor, lint, or a compiler. Just think how many problems could be caught before the communications arrived at the listener's auditory or visual interface! If we could communicate person to person using something that is as clean and as structured as a programming language like Python then I think that there would be a lot less confusion in the world. If our spoken word would fail to compile if it is incorrectly spoken, and if it failed to run if the assumptions it was built upon were incorrect, or were not fully specified then when what is spoken does successfully execute then there would be a much higher level of comprehension at the receiving end, and a high level of trust that what was received was exactly what was intended to be said. Using a structured communication mechanism like a programming language would also allow for clear and unambiguous responses or acknowledgments that what was said was received by the listener, and understood.

There would still be bugs of course, since nobody is perfect. But I expect that if you look at the number of times that what you speak or write is misunderstood or misinterpreted, or even just ignored, and compare that to the number of bugs in your software that have made it out to the customers, then I think that for almost all of us there would be a huge difference in those numbers. So what do you think, can Python 4000 be a spoken language?

My Mac Gripes

As mentioned before, my experiences with the new Mac haven't all been roses. There have been a few things that haven't worked out real great, and I've even had a few Grey Screens of Death (kernel panics.) I suppose that things like this happen on any computer system, but based on my prior experiences with Mac it kinda surprised me that there isn't a higher level of stability than what I've experienced. After all, this isn't Windows! I shouldn't need to have the "reboot" tool in my arsenal of troubleshooting aids. I have to admit though that if this had been a Windows box I probably would have needed to reboot at least a hundred times as much in the past few weeks than I actually have. But if it had been Linux it probably would have been about a tenth as many times.

However, stability issues aside, there are a few things that really bug me about the Mac and OS X experience, and that is what this article is about. I've been working off and on on this article for several weeks now. During that time I've added some things to the list, and also have removed several as I got used to them and was no longer able to gripe about them.

Read more…

Because I can...

For most of the time that I was actively using CVS (about a decade or so) if I wasn't using the command line interface then I most likely was using the pcl-cvs module for Emacs. It has a very good integration with emacs, with a dired-like listing of the files in the workspace that need some sort of attention. (They're modified, need updated, or etc.) It also apparently had very little overhead as the response time was always about as snappy as you could get with CVS, and when you're dealing with a source code repository with over 11,000 files in it every little bit counts. I tried a few other CVS-front ends over the years, but none of them seemed to suit me and my work habits very well. They either assumed too much or were too restrictive, in other words they got in my way more than they helped me to do my job.

A couple years ago OSAF switched from CVS to Subversion, and although I had played around with it a bit before this was my first real effort at using it. I love the advancements that SVN gives over and above what CVS can do, but I was very disappointed to find that the Emacs module for SVN (psvn.el) basically sucks. Although it provides an interface similar to pcl-cvs, it is very slow, often taking much longer to do something than it would take doing it from the command line, and it can sometimes block normal Emacs usage for a few seconds at a time while it churns at 100% CPU. So I looked at some other Free alternatives and didn't find anything that I liked. They were all either as slow or slower than the Emacs module, or they had the same problems that the CVS GUIs I had looked at had. So I gave up and used subversion from the command-line most of the time.

Now that wxWidgets has also switched to Subversion I started looking around for other solutions again... To my surprise I found that PySVN's WorkBench tool was a good fit for me. It's very fast at doing SVN operations, and it doesn't get in the way of how I work. I think I had dismissed it before mainly because it seems to be primarily intended as a test case and proof of concept for the PySVN Python extension module. So I started using WorkBench more and more and liked it more and more, but I also started noticing things that I didn't like as much, and some things that I thought could be done better, mostly UI and usability types of things. This brings me to the point of this article: WorkBench is Open Source so I could tweak it to my heart's content. And since it is written in Python and uses wxPython for the UI it is very easy for me to do so. And so that's what I've been doing off and on for the past couple months, and I have to say that it has turned out very well. Yesterday I submitted a big patch to the PySVN project, and although there are a few more things I would like to do to it, I am very happy with what I have done so far. And all of this is due to the Open Source nature of the project. Open Source allows me to make the tool be what I need it to be, and so I did it because I can.

wxPython 2.8.6.0

wxPython 2.8.6.0 has been released. Details are found here, and the download page is here.

An interesting thing about this release is that I made the build, uploaded about a gig's worth of installers and packages, and everything else that goes into making a release, all while being out of town and away from the machines doing all the work. I was able to make all the final tests and adjustments on my new Mac, using VMware Fusion for the Windows and Linux specific work, and then used Mercurial over an ssh tunnel to push my changes back home to my master build and release machine. The next part was easy, since I have been doing mostly automated builds for a few years now. I just start it going via a ssh login and then checked on it a few hours later from the hotel to see if it's done. At that point things started to get a little tricky, mainly because I usually do the rest of the release process by hand and in person. Since the full build is about a gigabyte of binaries I transfered just a few of them to my local machine for testing, and then I had to deal with uploading remotely from the build machine to SourceForge and our APT repository, all while I had a flaky wireless connection here and while attending various meetings. Then I realized that the software I usually use for editing the website is only installed on a machine at home. Well anyway, I muddled through and managed to get it done, and now I know where my release process could use a bit more streamlining and automation...

One month with Mac

It's been about a month since I switched my primary computer to a MacBook Pro, (2.4 GHz, 4G ram, with the new 17 inch hi-rez display) which I got for myself for my birthday. So I thought that this would be a good time for a review, and since I'm now a blogger it makes sense to share it with all of you too.

First a little background and why I decided to switch. For the past four or five years I've been using a Dell Inspiron 8200 laptop running Linux as my primary machine. By "primary machine" I mean the one where I do most of my development work, web browsing, email, word processing and etc. I also have a few other computers on and under my desk which are used for developing and testing wxPython on the various platforms I support, creating the binaries that I distribute, as well as some platform specific tasks. I was real happy using Linux as my primary desktop, especially for the last year and a half since I switched to Ubuntu. Almost everything I needed or wanted from my desktop system was available in one way or another, as well as plenty of things to satisfy my inner geek. However there were a few key things that prompted me to switch:

  • Even with the fantastic hardware support that Ubuntu has, I still had troubles with wireless networking, especially when trying to access a WEP protected network, and also troubles with suspending the laptop. Every time I suspended I had to cross my fingers and hope that it would come back in one piece. Even if it did restore, I usually had to restart some services, and it often would not suspend/resume more than a few times without needing a reboot. I knew that using an Apple notebook computer and OS X instead would give me excellent hardware support in these areas.
  • Ever since the advent of VMware I've used it to help me in my work, although after the Dell got to be a few years old it didn't feel fast enough to depend on it as a VMware host very much, especially since I had all these other computers on my desk running at native speeds. Also, since Apple doesn't allow OS X to be used in a virtual machine it wasn't much help there. However with a fast Mac with enough memory I could easily use it as VM host and run Windows and Linux VM guests on it, allowing me to have all the platforms I need for my work all wrapped up in nice a portable package.
  • Although there has been a lot of hype over the years about the premium you have to pay to have Apple hardware, I don't think that is very true anymore once you consider the quality of the hardware. Sure, you can get cheapo PCs and not have to lay out very much cash for them, but you pay for it down the road with upgrades and hardware failures. Once you start comparing high end, high quality hardware with good support, PCs and Apples cost about the same. I did a price comparison with Dell, choosing what I would get if I were to replace my old Dell with the new one, and it actually priced out at a couple hundred more than what I paid for the MacBook Pro. Of course that includes the Microsoft Tax which would have been wasted on that machine for me because I would have installed Linux on it first thing. (And getting Linux from Dell wouldn't have been an option because they don't offer it on the machine I would have bought from them.)

All in all the transition went a lot smoother than I expected. I've used Mac OS X for software development related tasks for a number of years now, but I had never really investigated what it would take for it to be my day-to-day machine. I knew my way around the file-system, using some of the applications that Apple ships with OS X, and a few of the Free and Open Source development related tools that I had installed, and also using the compiler and debugger, but that was about it. I was worried that there were too many things that I would miss from Linux, or that would be too difficult for me to get used to, or that something would go wrong, or that it would take too long to make the transition and that my work would suffer. But it just hasn't been the case. I had the old Dell and the new MacBook sitting side by side for a few days while I moved things over, and set up the new software, but I expected to need to do that for a week or two. One day I surprised myself when I realized that I hadn't even turned on the Dell for several days and that my setup tasks were way ahead of schedule. The hardest thing I dealt with was trying to decide which IRC client to go with. (I finally settled on Colloquy, but Linkinus was a close second.) Every time I went to look for some software to fill a need for something I used regularly on the old machine, I was able to find something that was either Free/Open Source or that was inexpensive shareware. The only commercial software that I've bought so far is VMware, but I expect to get one or two others.

So now the Dell has had its original Windows XP reinstalled and it has been recycled into being the first laptop for a member of my family. I've been using the Mac almost exclusively for a few weeks now, and it has been great. There are a few things that I don't like, or at least haven't adjusted to yet and it hasn't been quite as stable as I expected (more about these in another article) but all in all I've been very pleased with my choice.

The three main bullet points above have been satisfied very well. I've had no issues with networking at all, and it seamlessly transitions from wired to wireless and back with no interruptions in service. I've even had ssh sessions that remained connected when the wireless dropped for several minutes, and I was able to pick up where I left off when the wireless link came back again.

Sleeping and resuming works wonderfully, with no crossed fingers required.

And VMware Fusion has been a dream come true. Its support for Windows guests is not quite as polished as Parallels, (but it's only a 1.0 product so I expect that to improve over time,) and it's support for Linux guests far out-shines that of Parallels. There are a few features I miss from the VMware Workstation product available for other platforms, but they are not that critical for day to day operation. I'm able to have two "large" VMs running simultaneously and the computer doesn't even break a sweat. For CPU and disk intensive things like compiles the Linux virtual machine is actually much faster than doing the same thing directly on the Dell hardware was, although it's not as fast as running it on Cyclops, which happens to have the same CPU as the MacBook. (Cyclops is one of the Linux PCs under my desk which is used for making the wxPython binary packages for Linux) The Windows VM is also almost as fast for development work as the Windows PC I was using before. I still have that PC running because it is doing other things for me, but I've moved my development work to the VM because of the convenience factor. Incidentally, I can have compiles running in both VMs, and still be using the host machine's applications without noticing any slowdowns or jerkiness in their UI at all.

Well, I've rambled on long enough for one article. I've not yet covered all the things I thought I would in this post so I expect I'll make a few more on this subject over the next few weeks. Stay tuned.