wxForty-Two

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 the rest of this entry »

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

A few weeks ago I sent the following challenge to the PYxIDEs list, and I thought it might be a good idea to republish it here to give it a little more exposure. Read the rest of this entry »

The wxWidgets project is shooting for a quick turn-around on the 2.8.5 release and wants to get the 2.8.6 release out next week. So I am going to skip the wxPython 2.8.5.0 release entirely, and will go straight to a wxPython 2.8.6.0 release.

The upside is that some of the things fixed and polished in wxWidgets would have been problematic for some wxPython users, and so we'll skip those problems and not have to deal with them at all. (Some were bugs introduced by the fixes for other bugs, so you may not notice any changes at all compared to 2.8.4.2, other than the original fix.) The other upside of this skip is that all of the usual last-minute distribution related problems have already been worked out while I was working on doing a 2.8.5.0 build, and that should allow me to have the 2.8.6.0 build ready fairly soon after the wxWidgets release (or maybe even before if they wait a few days for the announcement like they've been doing lately.)

The downside is that I'm going to be on-site at OSAF all of next week celebrating the release of Chandler and planning Chandler's next steps, so I will likely be running this release build remotely. I guess I'll get a chance to see exactly where all of the holes in my automated build system really are!

Anyway, the preview build is in progress right now. If you're interested in testing or in having the bleeding-edge version of the binaries then keep an eye on the wxPython-dev mail list for an announcement from R'bot when he is done with the build and upload.