http://dilbert.com/strips/comic/2008-08-22/

enjoy!

    def finish_response(self):
        """Send any iterable data, then close self and the iterable

        Subclasses intended for use in asynchronous servers will
        want to redefine this method, such that it sets up callbacks
        in the event loop to iterate over the data, and to call
        'self.close()' once the response is finished.
        """

        if not self.result_is_file() or not self.sendfile():
            for data in self.result:
                self.write(data)
            self.finish_content()
        self.close()

So if you return a string to the handler it will send each character or byte of the string individually. For a multimegabyte file this can be quite slow.  The solution is to wrap any strings you return in a list. Alternatively if you are expecting a very large file, because file objects are iterable, you can return a file object directly.  There are likely some optimizations possible here but for my purposes this simple method works.  Here’s some example code to demonstrate the differences, first a simple server with methods to return as a string, as a list, and as a file, respectively:

from wsgiref import simple_server
import time

def returnAsString( env, start_response ) :
    t0 = time.time( )
    bytes = file( 'example.ppt', 'rb+' ).read( )
    t1 = time.time( )
    print 'Time to read %d bytes = %.2f seconds' % ( len( bytes ), t1 - t0 )
    headers = [ ('Content-type', 'application/vnd.ms-powerpoint' ) ]
    start_response( '200 OK', headers )
    return bytes

def returnAsList( env, start_response ) :
    t0 = time.time( )
    bytes = file( 'example.ppt', 'rb+' ).read( )
    t1 = time.time( )
    print 'Time to read %d bytes = %.2f seconds' % ( len( bytes ), t1 - t0 )
    headers = [ ('Content-type', 'application/vnd.ms-powerpoint' ) ]
    start_response( '200 OK', headers )
    return [ bytes ]

def returnAsFile( env, start_response ) :
    f = file( 'example.ppt', 'rb+' )
    headers = [ ('Content-type', 'application/vnd.ms-powerpoint' ) ]
    start_response( '200 OK', headers )
    return f

def exampleApp( env, start_response ) :
    '''dispatch to according to URL'''
    pathInfo = env[ 'PATH_INFO' ] 
    if pathInfo == '/returnAsString' :
        return returnAsString( env, start_response )
    if pathInfo == '/returnAsList' :
        return returnAsList( env, start_response )
    if pathInfo == '/returnAsFile' :
        return returnAsFile( env, start_response )
httpd = simple_server.make_server( 'localhost', 8081, exampleApp )
httpd.serve_forever( )

Then a simple driver using HTTPlib to make requests and time the results:

import httplib
import time

connection = httplib.HTTPConnection( 'localhost', 8081 )
connection.connect( )

t0 = time.time( )
connection.request( 'GET', '/returnAsString' )
data = connection.getresponse( ).read( )
t1 = time.time( )
dtString = t1 - t0
print 'Time to fetch %d bytes as string = %.2f seconds' % \
    ( len( data ), dtString )

del data
data = None
t0 = time.time( )
connection.request( 'GET', '/returnAsList' )
data = connection.getresponse( ).read( )
t1 = time.time( )
dtList = t1 - t0
print 'Time to fetch %d bytes as list = %.2f seconds' % \
    ( len( data ),  dtList )

del data
data = None

t0 = time.time( )
connection.request( 'GET', '/returnAsFile' )
data = connection.getresponse( ).read( )
t1 = time.time( )
dtList = t1 - t0
print 'Time to fetch %d bytes as file = %.2f seconds' % \
    ( len( data ),  dtList )

And the results:

Time to fetch 688128 bytes as string = 16.84 seconds
Time to fetch 688128 bytes as list = 0.01 seconds
Time to fetch 688128 bytes as file = 0.07 seconds

so you can see that pulling the entire file into memory and sending as one string by passing it back to the wsgi handler as a list containing the string is the fastest and returning one byte at a time is much much slower; returning the file object to the wsgiref handler is a good alternative as well.

The challenges include:

• must serialize Python objects/data to something that Actionscript can understand
• since slideboxx runs in the browser, it can’t see the filesystem so the server (Python) code needs to act as a proxy for interactions with the filesystem (I realize AIR applications can see the filesystem, but felt AIR would not be sufficiently familiar [yet] to our customers)
• many changes in application state, such as setting a preference, require a trip to the server — this is cumbersome but not technically challenging
• debugging can be difficult because you sometimes need to correlate tracebacks between client and server

Serializing the data is probably the most fundamental issue.  Fortunately it is generally easy to solve.  I use a mix of XML and JSON to serialize data.  The mix is partly historical and partly to fit in easily with the Flex framework. The historical part of this is that I originally wrote the slideboxx interface in Javascript using the YUI library and at that point YUI did not have JSON handling.  An example of fitting into the Flex framework is that XML result sets can be translated directly to ArrayCollections.  So for results that are going to target something like a Flex List component, returning an XML result set means I don’t need to write any parsing code.  The relevant part of the XML I use to pass slide search results from Python to Flex looks something like this:

<ResultSet>
    <Result>
        <ID>...</ID>
        <name>...</name>
        etc...
    </Result>
    <Result>
         ...
    </Result>
    ...
</ResultSet>

[Bindable]
public var feed:ArrayCollection = new ArrayCollection( );
...
private function resultHandler( event : ResultEvent ) : void {
    ...
    try {
        feed = event.result.ResultSet.Result; 
    } catcht( e : Error ) {
        feed = new ArrayCollection( ArrayUtil.toArray( event.result.ResultSet.Result ) ) ;
   }
   ...
}

<mx:TileList ... id="theList" dataProvider="{feed}" ...>
    <mx:itemRenderer>
        <mx:Component>
            <!-- put some custom component here that can bind some
                 the elements of each <Result>, these will be referenced
                 as "{data.<elementName>}" e.g., "{data.ID}" -->
        </mx:Component>
     </mx:itemRenderer>
</mx:TileList>

Now, I’m not going to “give away the farm”, but I am going to show you where it is…

To start with, you need the Python for Windows extensions (a.k.a. pywin32) package.  This gives you the bits you need to work with COM automation.  The other critical piece of information is the PowerPoint Visual Basic for Applications (VBA) reference — this is your map to the object model you access via COM.

Connecting to PowerPoint and opening a presentation is a few of lines of code:

import pythoncom
import win32com.client

pythoncom.CoInitializeEx( pythoncom.COINIT_APARTMENTTHREADED )
myPowerPoint = win32com.client.DispatchEx( 'Powerpoint.Application' )
thePresentation = myPowerPoint.Presentations.Open( ppt, True, False, False )

You can look up what to do with thePresentation object in the VBA reference (usually installed in C:\Program Files\Microsoft Office\OFFICE11\1033\vbapp10.chm (if not there, search your drive for vbapp10.chm).

For example, you can retrieve the number of slides in a presentation, via the Count property of the Slides collection:

nSlides = thePresentation.Slides.Count

When you’re done, be sure to clean up after yourself….

thePresentation.Close( ) #or thePresentation.Save(...), depending on what you need
del thePresentation
del myPowerPoint #the connection to PowerPoint
pythoncom.CoUninitialize( )

This approach to working with MS-Office documents will work for Excel and (presumably, I haven’t tried it myself) Word. There are some good examples for those applications in Mark Hammond’s “Python Programming on Win32″ (this book is extremely helpful if you’re doing Windows stuff with Python).

By using PowerPoint to “do the heavy lifting” as Joel Spolsky put it, we are able to use the same code to drive PowerPoint versions 2000 through 2007.  I’ve found the COM/VBA interface/API/whatever to be quite stable across PowerPoint releases.

Once you have the process identifier in hand using the method described in my previous post, you can get the handle to the process like this (assume pid is the process identifier returned by GetProcessID):

import win32api, win32con

handle = win32api.OpenProcess( win32con.PROCESS_TERMINATE, 0, pid )

If you already have the handle (e.g., if you had started the process in the same bit of code as Rajkumar did in his blog), then you can go straight to terminating the process:

win32api.TerminateProcess( handle, 0 )

win32api.CloseHandle( handle )

I’m not sure of the context in which the other author needed to kill a process, so the approach may not fit his needs.  Anyway, it’s an alternative in case anyone’s looking….

That’s all, hope it helps!

Since I started posting source code examples, I am using the awesome short code for WordPress.  I was a bit frustrated because the nice highlighting and line numbering wasn’t showing up.  I read somewhere that doesn’t work with all themes so I tried a bunch of themes.

It turns out everything looks great in IE or FireFox but you don’t get all the same goodness when viewing using Safari.  So, sorry to all you Safari users, I feel your pain.

Does anyone know why this happens in Safari?  and/or a way to make it work?

Thanks!

There’s a part of slideboxx where I need to find out whether a particular process is running. I used the method in killProcName.py referenced in “Python Programming on Win32″ (assuming you installed win32all a.k.a. pywin32 a.k.a. Python for Windows extensions, the code can be found in $PYTHONHOME\Lib\site-packages\win32\scripts). The code I was using looks something like this: 

import win32pdhutil
win32pdhutil.GetPerformanceAttributes( 'Process', 'ID Process', 'process_name' )
processIDs = win32pdhutil.FindPerformanceAttributesByName( 'process_name' )

This worked fine on my test system; however, I received reports from users that the functionality that called this code was slow. As an aside, it’s almost always a challenge to go from the report of “it’s too slow when I click on this” to knowing what part of the code is causing the problem, especially when you can’t reproduce the issue!  After narrowing down the issue, I hit up google for help and came across a newsgroup message with a solution and ended up using the following code:

import win32pdh
def GetProcessID( name ) :
    object = "Process"
    items, instances = win32pdh.EnumObjectItems( None, None, object,
                                                 win32pdh.PERF_DETAIL_WIZARD )
    val = None
    if name in instances :
        hq = win32pdh.OpenQuery()
        hcs = [ ]
        item = "ID Process"
        path = win32pdh.MakeCounterPath( ( None, object, name, None, 0, item ) )
        hcs.append( win32pdh.AddCounter( hq, path ) )
        win32pdh.CollectQueryData( hq )
        time.sleep( 0.01 )
        win32pdh.CollectQueryData( hq )

       for hc in hcs:
            type, val = win32pdh.GetFormattedCounterValue( hc, win32pdh.PDH_FMT_LONG )
            win32pdh.RemoveCounter( hc )
       win32pdh.CloseQuery( hq )
       return val

With that change in place, users reported no more lag in that part of the program. I don’t understand Windows internals well enough to know why there is a difference.  What I do know is that it works and it improves the user experience.  If anyone can explain the difference, I’d appreciate it (and I’m sure others would too) if you left a comment with an explanation.  Thanks!

Thanks again!

That’s the “love” part.  What about the “hate?”  We’ve all heard about “death by PowerPoint” and how to avoid it by listening to the good people who have advice on how to prepare and give good scientific and technical presentations.  They say it better than I can so I won’t belabor those points.  Another thing that frustrates me about PowerPoint in a research organization is how much information can be hidden away in PowerPoint slide decks, again it’s not PowerPoint itself but how people use it.

I’ve found through experience that no amount of organizational structure can solve the problem of information getting lost in PowerPoint presentations.  When you’re working on a team (even a team of one) each person’s way to organize will be different.  Who is to define the organizational structure? and will it make sense to anyone else? and who will enforce the structure?  I think all those questions lead to a waste of time and mental effort.  That’s one of the reasons we developed slideboxx: don’t worry too much about where to put the information, we’ll search for the slides!

In closing, I want to ask you: what are your frustrations with PowerPoint?  particularly in the culture around PowerPoint and how people use it in your organization?  Please leave a comment with your thoughts.  Thank you!

I’ve been developing in Python for about eight years, prior to Python I coded in Basic, Pascal, Fortran, C, Tcl, Expect, C++, Java, and Perl; so I’ve seen a few things. I settled on Python because my employer at the time used it, I continue to use it because I’ve not found another language in which I generally can get so much done in short periods of time. Part of it is the expressive syntax, and part of it is all the built-in libraries. I adore the significance of indentation, which almost forces one to write readable code. Python is the only language I’ve used where it is easy to figure out what you (or even someone else) meant by reading the code at a later time.

Python is expressive and efficient. It doesn’t take a lot of typing to get things done. slideboxx has an http server builtin, it talks to the frontend over http using XML and JSON, it also talks to the frontend using sockets, it stores some information in a relation database, it interacts with an indexing library, and controls PowerPoint using COM automation. slideboxx has a lot going on — all the bits you need for any Rich Internet Application (RIA, for short). The source code for slideboxx is less than 4000 lines of Python, and I don’t use a lot of tricks to make the code compact, I keep it simple so it’s easy to maintain. With some refactoring I could trim the LOC count.

Python includes a number of high-quality libraries built-in. As of Python 2.5 sqlite and ElementTree are there — a great embeded relational database and a nice simple way of dealing with XML. slideboxx is not computationally intensive so speed is not a huge concern. If it were, we’d rewrite the slow parts in C.

Now all this Python love doesn’t mean it’s right for you. I looked at using this project as a way to teach myself Ruby, but I knew that for me Python would be faster and could do everything. I’m hoping to do a Ruby project soon!

I believe in Python. I hope if you get a chance, you’ll give it a try on a future project!