A few months ago, I been successfully using TM for all sorts of Python scripts. I recently decided to use it again, but now scripts that used to run perfectly no longer do so. Here is the key: those same scripts still run perfectly if I run them from XCode, Editra, or if I make the files executables and run them from Terminal. They only fail in TM.
I have run into two problems. First, this simple one-line script will cause two error windows to appear: text = raw_input("--> ")
The first error window says, "The application Python quit unexpectedly. The problem may have been caused by the tm_interactive_input.dylib plug-in." The second error window says, "The application tm_dialog2 quit unexpectedly." I can paste the error reports here if you want to see them.
The second script that causes problems is this (reduced down to its essentials): import pyglet
class Test(pyglet.window.Window): def __init__(self): pyglet.window.Window.__init__(self)
def on_draw(self): self.clear()
test = Test() pyglet.app.run()
I get this error message: OSError: dlopen(/System/Library/Frameworks/AGL.framework/AGL, 6): Symbol not found: _CGLClearDrawable Referenced from: /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo Expected in: flat namespace
function __getattr__ in __init__.py at line 307 __import__(import_name) module body in __init__.py at line 133 from pyglet.gl import gl_info module body in __init__.py at line 99 from pyglet.gl.lib import GLException module body in lib.py at line 141 from pyglet.gl.lib_agl import link_GL, link_GLU, link_AGL module body in lib_agl.py at line 51 framework='/System/Library/Frameworks/AGL.framework') function load_library in lib.py at line 90 return self.load_framework(kwargs['framework']) function load_framework in lib.py at line 226 lib = ctypes.cdll.LoadLibrary(realpath) function LoadLibrary in __init__.py at line 408 return self._dlltype(name) function __init__ in __init__.py at line 325 self._handle = _dlopen(self._name, mode)
That error message makes it seem like a pyglet problem, but again, I get no errors when running it outside of TM.
I am running Mac OS X 10.5.6 and the cutting edge version of TextMate (1498), and I completely reinstalled TM after experiencing these errors. I am using the stock Python that shipped with Leopard (2.5.1) and that's the version being used by the Python bundle. There were two older MacPorts versions of Python that were carried over to my Leopard installation, but I have uninstalled those. I tried setting the TM_PYTHON variable, but it made no difference.
A simple pure-Python script that doesn't use pyglet or raw_input will run fine: class Test(object): def __init__(self): print("Hello, World")
test = Test()
Odd. Ideas?
Jim
On Feb 23, 2009, at 10:26 AM, Getzen wrote:
I have run into two problems. First, this simple one-line script will cause two error windows to appear: text = raw_input("--> ")
The first error window says, "The application Python quit unexpectedly. The problem may have been caused by the tm_interactive_input.dylib plug- in." The second error window says, "The application tm_dialog2 quit unexpectedly." I can paste the error reports here if you want to see them.
Well, I am not experiencing that problem here. Do you have any crash logs from textmate or from tm_dialog2 in ~/Library/Logs? If you try a simple ruby script with contents “gets” do you also get the crash, or is it only for python?
The second script that causes problems is this (reduced down to its essentials): import pyglet
class Test(pyglet.window.Window): def __init__(self): pyglet.window.Window.__init__(self)
def on_draw(self): self.clear()
test = Test() pyglet.app.run()
I get this error message: OSError: dlopen(/System/Library/Frameworks/AGL.framework/AGL, 6): Symbol not found: _CGLClearDrawable Referenced from: /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo Expected in: flat namespace
We have tracked this problem down. Basically, the tm_interactive_input.dylib that TextMate loads into Python requires a flat namespace to work properly. Pyglet loads OpenGL.framework but, because of the flat namespace, crashes when trying to load AGL.framework. I don't have a solution for you yet, but we're working on it.
—Alex
Alex Ross-8 wrote:
Well, I am not experiencing that problem here. Do you have any crash logs from textmate or from tm_dialog2 in ~/Library/Logs?
The only log in that location is textmate-io-exhaust.log. Here is the report text from the tm_dialog2 crash:
Process: tm_dialog2 [343] Path: /Applications/TextMate.app/Contents/PlugIns/Dialog2.tmplugin/Contents/Resources/tm_dialog2 Identifier: tm_dialog2 Version: ??? (???) Code Type: X86 (Native) Parent Process: Python [341]
Date/Time: 2009-02-24 18:18:37.840 -0500 OS Version: Mac OS X 10.5.6 (9G55) Report Version: 6
Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000008318 Crashed Thread: 0
Thread 0 Crashed: 0 dyld 0x8fe13b9d ImageLoaderMachO::preFetch(int, unsigned long long, ImageLoader::LinkContext const&) + 109 1 dyld 0x8fe14be4 ImageLoaderMachO::ImageLoaderMachO(char const*, int, unsigned char const*, unsigned long long, unsigned long long, stat const&, ImageLoader::LinkContext const&) + 628 2 dyld 0x8fe05bec dyld::loadPhase5open(char const*, dyld::LoadContext const&, std::vector<char const*, std::allocator<char const*> >*) + 1036 3 dyld 0x8fe05f71 dyld::loadPhase4(char const*, dyld::LoadContext const&, std::vector<char const*, std::allocator<char const*> >*) + 161 4 dyld 0x8fe06105 dyld::loadPhase2(char const*, dyld::LoadContext const&, char const* const*, char const* const*, std::vector<char const*, std::allocator<char const*> >*) + 325 5 dyld 0x8fe069e1 dyld::loadPhase1(char const*, dyld::LoadContext const&, std::vector<char const*, std::allocator<char const*> >*) + 209 6 dyld 0x8fe06a73 dyld::loadPhase0(char const*, dyld::LoadContext const&, std::vector<char const*, std::allocator<char const*> >*) + 67 7 dyld 0x8fe06bd2 dyld::load(char const*, dyld::LoadContext const&) + 130 8 dyld 0x8fe06df8 dyld::libraryLocator(char const*, bool, bool, char const*, ImageLoader::RPathChain const*) + 72 9 dyld 0x8fe0f22d ImageLoader::recursiveLoadLibraries(ImageLoader::LinkContext const&, ImageLoader::RPathChain const&) + 557 10 dyld 0x8fe0f13f ImageLoader::recursiveLoadLibraries(ImageLoader::LinkContext const&, ImageLoader::RPathChain const&) + 319 11 dyld 0x8fe1057e ImageLoader::link(ImageLoader::LinkContext const&, bool, bool, ImageLoader::RPathChain const&) + 62 12 dyld 0x8fe051ae dyld::link(ImageLoader*, bool, ImageLoader::RPathChain const&) + 158 13 dyld 0x8fe07acf dyld::_main(mach_header const*, unsigned long, int, char const**, char const**, char const**) + 2831 14 dyld 0x8fe01872 dyldbootstrap::start(mach_header const*, int, char const**, long) + 818 15 dyld 0x8fe01037 _dyld_start + 39
Thread 0 crashed with X86 Thread State (32-bit): eax: 0x00008324 ebx: 0x8fe13b44 ecx: 0x8fe3267c edx: 0x00001000 edi: 0x00006000 esi: 0x00007414 ebp: 0xbfffac38 esp: 0xbfffabd0 ss: 0x0000001f efl: 0x00010206 eip: 0x8fe13b9d cs: 0x00000017 ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037 cr2: 0x00008318
Binary Images: 0x8fe00000 - 0x8fe2db43 dyld 97.1 (???) <100d362e03410f181a34e04e94189ae5> /usr/lib/dyld
Alex Ross-8 wrote:
If you try a simple ruby script with contents “gets” do you also get the crash, or is it only for python?
No, a Ruby 'gets' works fine.
Jim
-
Alex Ross -
Getzen