Having said all that, threads in Python are still useful.  I will detail one example in which I spawn a thread to load a large binary file.  While this doesn’t spread the work across multiple CPU cores, it does enable the GUI to remain interactive while the file loads. All you have to do to create a Python thread is create a class that is derived from Thread. In the example below, I derived a class called Loader, which “wraps” the function that actually reads the binary files. The __init__ method accepts the filename and other options as arguments. The run() method is required. Don’t call run() directly–instead, call the start() method (inherited from the base class) to start the thread.

from threading import Thread

class Loader(Thread):
    """The Loader class is a derivative of Thread that allows file loading to take place in a
    separate thread from the GUI."""

    def __init__(self,fileName, readSecondDerivatives, monitor, notifyWindow):
        Thread.__init__(self)
        self._notifyWindow = notifyWindow
        self.fileName = fileName
        self.readSecondDerivatives = readSecondDerivatives
        self.monitor = monitor

    def run(self):
        """Required method that is run by Thread.start() calls the function that loads the binary."""
        binaryFile = open(self.fileName, mode='rb')
        self.data = readWGMfile(binaryFile, self.readSecondDerivatives, self.monitor)
        binaryFile.close()
        wx.PostEvent(self._notifyWindow, DataLoadedEvent(self.data))
####

Using the class:

loader = Loader(self.path+os.sep+self.fileName, readSecondDerivatives, monitor, self)
loader.start()

Even though this doesn’t create a true OS thread, it keeps the GUI from freezing, and allows the GUI to receive and display status updates from the file loading.

def readWGMfile(binaryFile, readSecondDerivatives, output=None):
    if output is not None:
        # allow the caller to hand in an alternative to standard out--for example, if
        # the caller is a GUI, redirect "print" statements to a GUI control
        print "Redirecting output..."
        import sys
        sys.stdout = output

    # rest of the function... 

I added an optional argument to the file reader, allowing the caller to specify an object to replace stdout. The sys module is then used to redirect stdout to the object specified by the caller. There’s no change to the default usage of the function, but it’s a lot more flexible. Here is the object that I defined to capture the text:

class Monitor:
    """The Monitor class defines an object which is passed to the function readWGMfile(). Standard
    output is redirected to this object."""

    def __init__(self, notifyWindow):
        import sys
        self.out = sys.stdout
        self._notifyWindow = notifyWindow        # keep track of which window needs to receive events

    def write(self, s):
        """Required method that replaces stdout."""
        if s.rstrip() != "":        # don't need to be passing blank messages
        #            self.out.write("Posting string: " + s.rstrip() + "\n")
        wx.PostEvent(self._notifyWindow, TextMessageEvent(s.rstrip()))

The only requirement of the Monitor class is that it implement a write(self, string) method that accepts a string that would otherwise have gone to standard out. In my case, I post a special event which is sent to the specified window. Here is the definition of that event:

class TextMessageEvent(wx.PyEvent):
    """Event to notify GUI that somebody wants to pass along a message in the form of a string."""
    def __init__(self,message):
        wx.PyEvent.__init__(self)
        self.SetEventType(TEXT_MESSAGE)
        self.message = message

Once again, I’m impressed with the way that Python makes hard things easy and very hard things possible. In my next post, I’ll give a quick example of how easy it is “thread” things in Python.

I will soon post a clever scheme to capture text output from the file-reading function, and display it in the GUI, without making substantial changes to the file-reading function.

The first thing to realize is that the Labview binary file is a direct dump of the data that was stored in RAM. How Labview stores data in memory is documented here. Indirectly, this documents how binary files are stored on disk. Our DAQ program writes a rather complex “cluster” (Labview’s version of a C structure) to disk. The elements of the cluster are stored contiguously as a sequence of bytes, and there’s no way to know which byte goes with which element, unless you know the size of each element and the order in which they are stored in the cluster. So, the first step is to document the cluster that’s being written to disk. You can use the context help in Labview to view the data type of the wire that leads to the VI that writes the file. With this in hand, you are ready to write Python code.

First, make sure you open the file in binary mode:

binaryFile = open("Measurement_4.bin", mode='rb')

Now you can use the file.read(n) command to read n bytes of data from the file. This data is read as a string, so you will need the struct module to interpret the string as packed binary data. This is what it looks like:

 (data.offset,) = struct.unpack('>d', binaryFile.read(8))

The first argument to struct is a format string. The ‘>’ tells struct to interpret the data as big-endian (the default for Labview) and the ‘d’ tells it to produce a data type of double. The data type has to match the number of bytes read in by file.read(). Remember that we’re reading the file sequentially, and there are no delimiters, so if you read in the wrong number of bytes for any data, all the subsequent data will be junk.

One final note about arrays: arrays are represented by a 32-bit dimension, followed by the data. If the array contains no elements, it is stored as 32 zero bits with no other data. It would probably be a good idea to use the Python array module if you need to read in large arrays efficiently.

I haven’t been blogging much because I haven’t done much software development, Linux admin, or lighting design lately.  I have been busy in the lab at work and I’ve been supervising a trainee lighting operator instead of running my own shows.  We haven’t been moving forward with plans to purchase a new lighting control console, so no update on that, either.  Hopefully, I’ll have something interesting to post soon.

It will prompt you for your password.  You might need to tweak the options–for example, the noperm option prevents Linux from trying to map Windows permissions to Linux permissions. This is necessary on my network to enable Linux to copy nested directories to the Windows share. Once you get it working, it can be added to fstab like any other file system.
//xx.xx.xx.xx/sharename /mnt/server cifs user,credentials=/etc/cifs_credentials,noperm 0 0

The cifs_credentials file can have any file name, in any location you choose, with the format described in the man page for mount.cifs.   Since this file will contain your network login and password, make sure it can be read only by root or the user who owns those credentials.

For reference: mount-cifs thread on the Ubuntu forums

BTW, isn’t it about time I created a “linux” category instead of trying to stuff my Linux entries under the “software development” category?

Practically speaking, when a Color Palette is visible on camera,we can only get seven full-intensity colors: red, blue, green, white, purple, blue-green, and yellow.   We’ve since moved them out into the auditorium where they are used to illuminate the walls.  We did find one really cool application for these lights.  We have a number of deep-purple, “blacklight” Color Palettes mounted backstage to enable people to move in the dark.  They stay on all the time, draw very little power, and are totally invisible to the audience, even during a dead blackout.

This is a Chauvet COLORado 1, which is meant to replace a small par can. It’s mounted on a pipe above and behind the musicians and lights them from behind.  This is the view you get from the front row in the audience.  See the red, blue, and green LEDs?  That’s producing white light, but you wouldn’t know it from this angle.  That’s what happens when the colors don’t mix at the light.  We don’t have the strobing problem on video with the COLORado’s, but I don’t know if that’s due to their positioning or their design.

For more information, see the LED lighting reviews by onstagelighting.co.uk.  There are also pro-grade LED fixtures that are much better…but I haven’t used them.

Here is a look in another color.

I didn’t think to take close-up pictures of this set.  It turns out that our set designer likes to have these pictures, so now I’m trying to do a more thorough job.   This one is constructed of a wooden frame with a light colored wrinkly fabric stapled to it.  Like I said, I don’t design or build these things, but if you want to know the details, I’m sure I can find out for you.