August 31, 2004
Linux Desktop Woes
Another day, another frustration with the state of the Linux desktop. Today's issue-ette is the display of PDF files.
I downloaded a couple today, and I couldn't get either to display properly under KDE. As far as I can tell, the problem is with the version of gv I'm running. Although according to Debian it is up to date. It had decided that the landscape document I've got is actually in portrait format, so I lose the right third of each page.
I can't find a way to rotate the display of pages by ninety degrees. There is a View menu where I can choose between portrait or landscape but it always rotates the page just the wrong way. Switching a landscape document to landscape view causes the page to display at ninety degrees to the correct orientation with the left edge displayed at the top and the top edge displayed on the right. Switching to portrait mode causes the aforementioned loss of the right side of the page.
Contrast this with my iBook where Preview displays both files without a problem.
Update. Courtesy of ludoo in the comments I'm now a happy PDF viewer thanks to XPDF.
Posted by Andy Todd at 09:22 PM | Comments (4)
August 19, 2004
PythonCard 0.8
PythonCard is a GUI construction kit for building cross-platform desktop applications on Windows, Mac OS X, and Linux.
Release 0.8 includes over 50 sample applications and tools to help users build applications in Python, including codeEditor, findfiles, and resourceEditor (layout editor). A list of changes since release 0.7.3.1 is available in the changelog file. New samples include ataxx, lsystem, moderator, montyhall, mp3player, reversi, twistedEchoClient. There is also an experimental reStructuredText and HTML editor in the codeEditor directory called restEditor.py.
PythonCard requires Python 2.3 or later and wxPython 2.5.2.7 or later.
You can download the latest release at:
http://sourceforge.net/project/showfiles.php?group_id=19015
The eagle eyed will notice that the package name (at SourceForge) has changed. This is the first step on the path to the mythical 1.0 release. Please be sure to look at the migration_guide.txt file in the docs directory if you are upgrading from a previous release. Since the package name has changed, you can continue to use the older PythonCardPrototype package simultaneously with the new PythonCard package, but you must upgrade to wxPython 2.5.2.7.
All the information you need about PythonCard can be found on the project web page at: http://pythoncard.sourceforge.net/
The installation instructions and walkthroughs are available on the main documentation page: http://pythoncard.sourceforge.net/documentation.html
For a list of most of the samples that have been built with PythonCard and screenshots of them in action go to: http://pythoncard.sourceforge.net/samples/samples.html
The kind people at SourceForge host the project: http://sourceforge.net/projects/pythoncard/
If you want to get involved the main contact point is the Mailing list: http://lists.sourceforge.net/lists/listinfo/pythoncard-users
Additional Notes:
Remember to backup or just delete your old PythonCard directory before installing a new version, so that the old files aren't still in the package directory. If you installed a previous version of PythonCard on Windows using the binary installer, then you should be able to remove the old package via the Add/Remove Programs Control Panel.
The distutils installer will put the framework, components, docs, samples, and tools in Lib\site-packages or your Python directory (typically C:\Python23). Of course, on Linux and Mac OS X that path will be slightly different and have forward slashes.
Windows users should get a PythonCard menu in the Start->Programs menu with links to the documentation, samples, codeEditor, findfiles, and resourceEditor.
The tools and most of the samples will now keep their config and data file info in the "pythoncard_config" directory created by the framework. On Unix, the directory will be ~/pythoncard_config. On Windows, the directory varies as described in the following post:
http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/1496793
So, if you run a PythonCard app with any of the runtime tools and select "Save Configuration" from the "Debug" menu, the window positions and sizes of your runtime windows (Shell, Message Watcher, etc.) will be saved in "pythoncard_config/pythoncard_config.txt" not the PythonCard directory. Likewise, when you change the text style used by the codeEditor via the "Styles..." menu item under the "Format" menu, the modification will be saved in "pythoncard_config/stc-styles.cfg"
Posted by Andy Todd at 07:14 PM | Comments (0)
My PyBlosxom Flavour
A recent post on the PyBlosxom Users mailing list included a request for more sample flavours (or templates as other blogging systems call them). Always obliging, here are mine. Click on the screenshot to the left for a full size version, which looks spookily like this page.
If you download them please be aware that I run the comments plugin and this requires extra files.
I've also included my CSS stylesheet file as this controls the look and feel of the site, which is most of what is required after all. Hopefully the structure of the template lends itself to different displays based solely on CSS, but I leave that as an exercise for the interested reader.
There may be some changes required, so I'll leave this entry as the permanent home of this flavour, and hopefully link to it from the flavour registry. If you want something that looks a little different try there, you never know what you might find.
Posted by Andy Todd at 04:38 PM | Comments (1)
August 18, 2004
Python People Are Very, Very, Nice
This recent thread on comp.lang.python is another example of Python programmers just being nice. On many other newsgroups the original poster would have been ridiculed and vilified, never to return.
Someone new to the language wants to understand how to work with databases. He has skimmed the documentation but, (and this is my opinion, so don't shoot me) not taken the time to actually read the documents or even try any of the example code.
But the Python approach is to empathise and explain, usually until the solution to your problem has been explained in so many different ways that you have forgotten the original question. In this case a number of people chip in, all adding little nuggets of knowledge building on the original (quite comprehensive) reply to the original post.
This is another reason, if one were needed, why I like programming in and hanging around with people who program in Python.
If you are interested, the thread I have linked to is an interesting explanation of how to get rich objects back from a database cursor execute.
Posted by Andy Todd at 10:38 PM | Comments (2)
August 04, 2004
Extended Print Form
In all of this discussion of function decorators there have been a few mentions of the extended print syntax (>> - also known as print chevron). I've never used it and wondered how useful it would be and, more importantly, how to invoke it.
I could find the language lawyer definition of the syntax, but that's a little tricky and a quick google could find no examples that actually worked. I even looked in the tutorial but came up with nothing either.
It took me a couple of goes, probably because I'm not very good at reading the Python grammar notation, but here is my example;
>>> myFile = file('/tmp/chevron.log', 'w+')
>>> print >> myFile, "A line of text to append to the file"
Update Thanks to Fredrik and Malcolm for pointing out the missing chevrons, they should now be back. I'd also like to point out that I wasn't complaining about the implementation, rather that I couldn't find any examples of how to use it after a superficial search.
Posted by Andy Todd at 10:16 AM | Comments (5)
August 03, 2004
Python Decorators
It's all kicking off in blog land - see Ian Bicking and the Effbot on the latest Python language feature, function decorators.
I broadly agree with these two august gentlemen. It doesn't look nice and I'm not sure when I would use it. At first glimpse it doesn't look very Pythonic, so my initial reaction is that we are probably better off without it.
But then again, life was always better a few years ago, wasn't it? Change is bad, the Daily Mail is good ;-)
In the end, it is Guido's language and he can do what he likes with it. Let's see how this works out and then round him up and chastise him if it all goes horribly wrong.
Posted by Andy Todd at 10:11 PM | Comments (2)
August 01, 2004
Towards a Consistent Database API
Python has a Database API standard, but as is frequently argued on the DB-Sig mailing list it's not quite standard enough.
What do I mean by this? The standard is flexible, essentially making each module which implements it subtly but meaningfully different. I've recently been trying to write some code which can seamlessly access different databases. The ambiguities of the DB-API make it difficult, if not impossible, to write one series of statements which will work against either database. In this case it has been Gadfly and MySQL, but writing code to work against more than one database will cause some degree of problems. These inconsistencies are, I think, one of the reasons that people have written abstraction layers like db_row, dtuple and PDO.
Typically these inconsistencies would be quite simple to fix, but require a little work on the part of module authors.What do we need? Here is my list;
- A single, consistent, parameter style. Gadfly uses '?' and MySQLdb uses '%s'. We should pick one and stick with it. [1]
- Consistent behaviour. When you fetchone() result from a Gadfly cursor that is empty it raises an exception (gadfly.database.error). MySQLdb just returns 'None'. [2]
- Consistent use of exceptions. The DB-API specifies a standard set of exceptions, but doesn't say when they should be raised. What should happen if I attempt to execute an invalid SQL statement? Some modules will accept it and return nothing whilst others will raise an exception. With a bit of luck it might even be ProgrammingError.
I have probably missed some things from my list, so go wild in the comments if you think that there are other areas ripe for clarification. Who knows, I might even post this to the mailing list and see if we can't get some movement on these issues.
[1] - Life gets tricky when you consider named parameter styles, like the one used in cx_Oracle. I think that's the best way to write code but not enough module authors agree with me. JDBC, ODBC and the Perl DB:API all use '?' so that should probably be the Python standard as well.
[2] - In fact, MySQLdb tells you the number of rows affected as the return code of the execute, so that you don't need to even attempt the fetchone.
Posted by Andy Todd at 03:59 PM | Comments (7)
Installing Jakarta-Tomcat on Debian
According to this excellent guide to installing Jakarta-Tomcat with Apache on Debian I need to get and install a JDK myself. Specifically it recommends the 1.18 JDK for Linux from IBM. Sadly the page that is mentioned when I install the Debian package ( http://www.ibm.com/java/jdk/118/linux/ ) no longer works. Which stumps me somewhat.
The prognosis isn't good, according to this bug report the package is moribund. So is there a way to get Tomcat working under Debian that neither I nor Google know about?
Posted by Andy Todd at 02:50 PM | Comments (2)