I'm excited to be working on this project. Not just because of wxPython, but also because I have previous experience with the subject matter. My first major job out of college was working on software products that had a lot of the same goals as the IntúaSolutions products: essentially to be a highly dynamic and flexible solution for collecting and reporting medical patient care data in hospitals. The key here is the "highly dynamic and flexible" part, the intent is to have a set of domain-specific tools where unskilled (a.k.a non-programmers) but knowledgeable people can easily tailor the application to the needs of each hospital, or even each department within the hospital. My former experience with this was back in the dark days of DOS so the products had only a textual user interface, but I think we managed to accomplish a lot with it and it was a very successful product line, and at least as of a few years ago it was still going strong, although they've modernized a bunch of things since I worked there.

Obviously a few things have changed in the computer world since then. I discovered Python a year or so after I left that job and I've always wondered what it would have been like if we had used Python as the internal macro/calculation/filtering/query language instead of our home-grown RDL (for anyone outside of the marketing group and the customers that acronym stands for Robin Dunn's Language, otherwise it is Rule Definition Language.) Since that time we've also gone through the rise of the graphical user interface, the explosion of the World Wide Web, and my current notebook computer has 7.5 times the number of pixels on screen and 8 times more RAM than the hard drive space in the brand new top of the line desktop computer I had when we started that project! It should be fun to be able to apply modern technology and my new skills to similar features and issues that I dealt with 14-18 years ago.

I've linked to this video as a way to let you know how big of an effort this job search seemed to be at times, and also how good it felt when it was finally complete.

"...Autotools, an intractably arcane and grotesquely anachronistic cesspool of ineffable complexity that makes even seasoned programmers nauseous."

I think that sentence could win an award if there was a most-big-words-used-where-small-words-would-do-fine contest. Good thing that my dictionary is only a Spotlight search away... [type][type][type]... Ah so that's what it means. Yes, I agree. <wink!>

The Open Source Applications Foundation has been sponsoring my work on wxPython for about 5 years now. I spend about half of my time working on Chandler, supporting the other OSAF engineers with wxPython questions or problems, or in working on specific needs that OSAF has in wxWidgets or wxPython itself. I'm free to spend the other half of my time working on wxWidgets or wxPython in whatever way I want. Typically I use a big chunk of this time supporting the wxPython community, answering questions on the mail lists, tracking down bugs that people report, etc. but I also work on other features or long-term goals for wxPython that may not necessarily line up with some immediate need that Chandler has. It's been a real good deal for everybody involved. I've been able to get paid for working on my favorite hobby, the Chandler project has gotten the support and expertise that they needed, the wxPython community has also had a large block of my time and attention, and wxPython itself has had many improvements and enhancements that I likely would not have had time for otherwise.

This week OSAF announced a restructuring and downsizing of the Chandler team. They want to shift the focus more towards gaining more users and, since it is an Open Source project, the building up of a volunteer developer community. The other goal behind the transition is a desire to stretch out the remaining funding until the project can find a way to become self-sustaining. As you've probably guessed by now, I was not one of the worker bees kept in the hive. I've got a few weeks left on my contract and then I'll be making my own transition to something else. Although I've known this was coming, I didn't expect it until the end of this year, so it's still a bit of a disappointment.

So what does this mean for wxPython? Hopefully nothing, other than some reduction in the time I am able to spend focused on wxPython. It would be great to be able to find someone willing to support my working on wxPython part time like OSAF did, but it's probably pretty unlikely that that particular lightning will strike in the same place twice. On the other hand, I expect that my next gig will be something that at least uses wxPython so there will be some opportunities for some of that work to roll down to wxPython and the community. Of course, on the gripping hand, if you or somebody you know would be interested in sponsoring at least part-time work on wxPython, please do contact me.

Update: This news was noticed by the New York Times.

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!

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 hight 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?

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.

(more...)]]> http://wxPython.org/blog/2007/11/20/my-mac-gripes/feed/ http://wxPython.org/blog/2007/09/28/because-i-can/ http://wxPython.org/blog/2007/09/28/because-i-can/#comments Fri, 28 Sep 2007 22:30:54 +0000 Robin http://wxPython.org/blog/2007/09/28/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.

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

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.