I guess a more fundamental question is: does SDL on Darwin imply Cocoa?
That's anyone's guess, but that's the impression I got from the tip page. Lots of people seem to have run into this error with SDL, and that was the only page I came up with that offered anything remotely looking like a solution.
I'm only using the SDL (via GLUE) pike bindings on an OS agnostic application (aido), but it presently does not work on my macbook, so I've been chasing the issues.
Even getting a minimal GLUE app not to crash would be good progress:
#! /usr/local/bin/pike77
int main() { GLUE.init( (["title":"Glue example"]) ); draw_frame(); return -1; }
void draw_frame() { call_out(draw_frame, 0.02); do_gl_code(); GLUE.swap_buffers(); }
void do_gl_code() { GLUE.draw_line( 1.0, 1.0, 1.5, 1.5, Image.Color.red ); }
Apparently, SDL on OSX does employ Objective-C. That means, at the very least, you'll need to wrap all of your SDL code with an NSAutoreleasePool. Now, depending on how much Objective-C is being used, you'll need to release the pool every so often, otherwise, you'll tie up a huge chunk of memory for unreleased objects.
Perhaps you'd like to try it along with Public.ObjectiveC, which should at the very least, give you an easy mechanism for freeing the pool from within Pike code.
Bill
On Sun, 29 Jul 2007, Johan Sundström (Achtung Liebe!) @ Pike (-) developers forum wrote:
That's anyone's guess, but that's the impression I got from the tip page. Lots of people seem to have run into this error with SDL, and that was the only page I came up with that offered anything remotely looking like a solution.
Apparently, SDL on OSX does employ Objective-C.
Unfortunate. I guess the first attempt will be getting something to work at all, using mixed components from your back yard, then. :-)
That means, at the very least, you'll need to wrap all of your SDL code with an NSAutoreleasePool. Now, depending on how much Objective-C is being used, you'll need to release the pool every so often, otherwise, you'll tie up a huge chunk of memory for unreleased objects.
Okay. I'm sure experience will show once I'm far into it enough to see what happens when it no longer segfaults.
Perhaps you'd like to try it along with Public.ObjectiveC, which should at the very least, give you an easy mechanism for freeing the pool from within Pike code.
I think I'm past the initial hurdle of finding the above (after a few failed attempts with pike -x monger :-) --
wget http://hww3.riverweb.com/dist/Public_ObjectiveC_Tiger.tar.gz tar zxf Public_ObjectiveC_Tiger.tar.gz mv Public.pmod ~pike77/lib/modules/
Then I'm stuck. I assume I should do something clever first in the init() and last in the exit() of GLUE.pmod/Drivers.pmod/SDL.pike, likely involving Public.ObjectiveC.Cocoa.NSAutoreleasePool, but I'm not quite sure what nor how; I have used ObjectiveC neither in glued nor raw form in my day yet, so I am kind of lost. :-)
Taking further wild shots in the dark, does the tweaking hinted above mean the occasional Public.ObjectiveC.purge_autorelease_pool() call? (Well, maybe I'm better off not applying any wild guesswork here. :-)
Are there any handy #ifdef __DARWIN__ or similar I might want to wrap code doing these things in, by the way, and what would they be named? Alternate interesting question: how do I list all #defines defined in a pike level compile unit?
pike-devel@lists.lysator.liu.se
-
H. William Welliver III -
Johan Sundstr�m (Achtung Liebe!) ＠ Pike (-) developers forum