Problems with OS X Lion in home directory

[Dave Musicant]

Hey folks -

We're having a wacky problem in our labs trying to run pyprocessing on OS X Lion. We've installed it via the easy_install instructions, and set the Python preferences to 32 bit in order to get it to run. It works great, except when the Python program to be run is sitting at the top level of my home directory. For example, if I run

python ~/prog.py

from anywhere in my account it does not work (spinning beach ball, and graphics window doesn't appear).. but if I put the program anywhere else, such as ~/temp/prog.py, or whatever, it does work. We're racking our brains trying to figure out what kind of configuration problem could cause it to fail based on the location of the file itself. When pyprocessing hangs (and we've verified that it happens right at the import statement), and we hit ctrl-c, we see the following traceback. Any thoughts? Thanks...

Traceback (most recent call last):

  File "../process.py", line 1, in <module>

    from pyprocessing import *

  File "/Library/Python/2.7/site-packages/pyprocessing-0.1.3.22-py2.7.egg/pyprocessing/__init__.py", line 56, in <module>

    from pimage import *

  File "/Library/Python/2.7/site-packages/pyprocessing-0.1.3.22-py2.7.egg/pyprocessing/pimage.py", line 3, in <module>

    from globs import *

  File "/Library/Python/2.7/site-packages/pyprocessing-0.1.3.22-py2.7.egg/pyprocessing/globs.py", line 48, in <module>

    class attrib:

  File "/Library/Python/2.7/site-packages/pyprocessing-0.1.3.22-py2.7.egg/pyprocessing/globs.py", line 58, in attrib

    location = pyglet.resource.FileLocation(os.path.dirname(__file__))

  File "build/bdist.macosx-10.7-intel/egg/pyglet/__init__.py", line 306, in __getattr__

    

  File "build/bdist.macosx-10.7-intel/egg/pyglet/resource.py", line 680, in <module>

  File "build/bdist.macosx-10.7-intel/egg/pyglet/resource.py", line 291, in __init__

  File "build/bdist.macosx-10.7-intel/egg/pyglet/resource.py", line 335, in reindex

  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/os.py", line 294, in walk

    for x in walk(new_path, topdown, onerror, followlinks):

  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/os.py", line 294, in walk

    for x in walk(new_path, topdown, onerror, followlinks):

  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/os.py", line 294, in walk

    for x in walk(new_path, topdown, onerror, followlinks):

  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/os.py", line 294, in walk

    for x in walk(new_path, topdown, onerror, followlinks):

  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/os.py", line 294, in walk

    for x in walk(new_path, topdown, onerror, followlinks):

  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/os.py", line 294, in walk

    for x in walk(new_path, topdown, onerror, followlinks):

  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/os.py", line 276, in walk

    names = listdir(top)

KeyboardInterrupt

[Victor Norman]

I was having the same problem and figured out what was happening (by using dtrace on the running python executable).

The problem is the pyprocessing loads pyglet.resources, and for some reason that module seems to walk through every directory and file starting at the current working directory.  So, if you cd to a directory with few or no subdirectories and few files in it, then when you import pyprocessing it starts up much more quickly.

Vic