Pages: [1]
  Print  
Author Topic: OS X, libtcod, and python... foilsome!  (Read 1553 times)
devilmouse
Apprentice
*
Posts: 4


View Profile
« on: August 04, 2010, 09:31:38 PM »

How fist-shakingly infuriating! Let's assume for a second that I'm a stubborn fellow and want these to play nicely together so I can develop on my mac with python (instead of using c/cpp). The c/cpp samples work fine and dandy, but getting python to work? Ugh.

I've built the .dylib (the mac equivalent of a dll/so) and python can load it without a problem, but as soon as samples_py.py tries to run (using pythonw, the OS X way to run python code with GUIs):
Code:
libtcod.console_init_root(80, 50, 'libtcod python sample', False)
the terminal barfs and spits out:
Code:
Python[72013:60f] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Error (1002) creating CGSWindow'
along with a long stacktrace (the most relevant sections being):
Code:
11  libSDL-1.2.0.dylib                  0x000000010222733f SDL_SetVideoMode + 527
12  libtcod_debug.dylib                 0x00000001021c534f TCOD_sys_init + 755
13  libtcod_debug.dylib                 0x00000001021a4056 TCOD_console_init + 390
14  libtcod_debug.dylib                 0x00000001021a3ece TCOD_console_init_root + 279

Googling around, there's some strangeness with how OS X deals with making UIs and some people suggested using pygame to do the heavy lifting via putting this at the top of the samples_py.py (or libtcod.py):
Code:
import pygame
pygame.init()
which sadly results in a seg fault in pygame.

Some other sites reported a possible issue with the way applications register on the Mac and there was a bunch of ObjC that I didn't understand, and I didn't want to try to start understanding ObjC (though maybe that's the next step?).

Something's amiss and I'm running out of possible ideas. I imagine I'm not the first to try to cross this chasm (nor will I be the last), but if anyone's had any further success here, I'd be much obliged.
Logged
Jotaf
Global Moderator
Master
*****
Posts: 1183


View Profile
« Reply #1 on: August 04, 2010, 10:59:30 PM »

Actually, a little while ago the library wouldn't even compile under Mac, let alone run properly within an Objective C application (or whatever; I'm not a Mac dev expert Grin ) . You have to thank Pender for going through a lot of trouble to get it to that state. Relevant topic in this forum:

http://doryen.eptalys.net/forum/index.php?topic=417.msg3439

Even that is highly experimental. Keep in mind that what you wanna do is entirely new here: no one has tried that before. I hope you succeed though, as another platform-language combination is always welcomed. I'd love to help but I don't own a Mac, so there isn't much I (or Jice, or Mingos) can do, except providing assistance from the sidelines Undecided
Logged
devilmouse
Apprentice
*
Posts: 4


View Profile
« Reply #2 on: August 05, 2010, 02:05:52 AM »

Python's just the next logical step! Being able to link against c/c++ projects on the mac is awesome so props to Pender for that, but I am lazy and have a fondness for python and thus continue to bang my head against this wall.  Grin

I'll probably abuse this thread and use it as my teddy bear (http://blog.jgc.org/2010/05/talking-to-porgy.html) in attempts to suss anything out!
Logged
Jotaf
Global Moderator
Master
*****
Posts: 1183


View Profile
« Reply #3 on: August 05, 2010, 03:12:31 AM »

Hehe awesome! I knew about rubber ducking but never had it explained in such an amusing way, and with all the fun facts. If it worked for Alan Turing it must work for us! Also if I ever find myself bothered by too many folks asking questions I have to remember that Wink

This thread may be better than Porgy though, there's a chance someone here can actually help Smiley
Logged
devilmouse
Apprentice
*
Posts: 4


View Profile
« Reply #4 on: August 05, 2010, 04:32:18 AM »

Progress, kind of?

By grabbing the PyObjC module, and putting this at the top of libtcodpy.py
Code:
from AppKit import *
NSApplicationLoad()
I'm able to pop up a window of the appropriate size in the samples_py.py, but hopes are quickly dashed upon executing the first file parser tests!
Code:
struct=libtcod.parser_new_struct(parser, 'struct')
Kaboom, segfault.
Code:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000004d6d720
0x00000001021bd472 in TCOD_parser_new_struct (parser=0x4d6d720, name=0x10042cf24 "struct") at src/parser_c.c:548
548  TCOD_list_push(((TCOD_parser_int_t *)parser)->structs,ent);
Looking through the debugger, the cast parser pointer has no structs.

Similarly, if I skip the file parser test, it dies on
Code:
libtcod.console_clear(sample_console)
with
Code:
Reason: KERN_INVALID_ADDRESS at address: 0x00000000027d9f6c
0x000000010219f690 in TCOD_console_clear (con=0x27d9f50) at src/console_c.c:271
271  for (x=0; x < dat->w;x++) {
And in this case, dat's w is null.

I think my ctype bindings might be busted or something similar at this point, but I don't know enough about python->C stuff to really guess more than that right now (and that guess is probably wrong anyway!). HMM!
Logged
devilmouse
Apprentice
*
Posts: 4


View Profile
« Reply #5 on: August 05, 2010, 01:23:29 PM »

Thinking about it this morning, but not being at home to look... I'm going to wager that it's a 32-bit v 64-bit problem. Pointers are probably not aligned or some such. Maybe? The adventure continues. Whee!
Logged
Pages: [1]
  Print  
 
Jump to: