Recently I’ve converted a SDL/OpenGL app with python embedded to a
python library.
Under MacOS X I get hundreds of NSAutoreleaseNoPool errors when the c
code calls SDL_Init_Video.
The problem, I believe, is that under MacOS X SDL is implemented upon
Cocoa. It expects that I run an application with a main(). But in my
case the main loop is in the python script, which call SDL_Init_Video
and everything else in a function inside the c extension.
Can you not call the initialization that is in SDLmain.m normally in
from your library?
I’ve tried it. but I can’t figure out how to call objective c code from
c code.
Also, I want to keep the compilation easy (I use python distutils to
make the module).
I’ve partially solved calling NSApplicationLoad() before creating the
window.
Now I get some leaks as before but the app works, even if I can’t
receive keyboard events in
windowed mode.
It seems to me that I can’t stick to plain c in the macosx code, like I
did for win and linux version.
Maybe there’s a plain c api to just initializa Cocoa, disable what I
guess is a kind of obj-c garbage
collection, and give focus to the sdl event manager in my window?
Thanks, by now.
c.>> /Recently I’ve converted a SDL/OpenGL app with python embedded to a
/>/python library.
/
/Under MacOS X I get hundreds of NSAutoreleaseNoPool errors when the c
/>/code calls SDL_Init_Video.
/>/
/>/The problem, I believe, is that under MacOS X SDL is implemented upon
/>/Cocoa. It expects that I run an application with a main(). But in my
/>/case the main loop is in the python script, which call SDL_Init_Video
/>/and everything else in a function inside the c extension.
/
Can you not call the initialization that is in SDLmain.m normally in
from your library?
/Recently I’ve converted a SDL/OpenGL app with python embedded to a
/>/python library.
/
/Under MacOS X I get hundreds of NSAutoreleaseNoPool errors when the
c
/>/code calls SDL_Init_Video.
/>/
/>/The problem, I believe, is that under MacOS X SDL is implemented
upon
/>/Cocoa. It expects that I run an application with a main(). But in
my
/>/case the main loop is in the python script, which call
SDL_Init_Video
/>/and everything else in a function inside the c extension.
/
Can you not call the initialization that is in SDLmain.m normally in
from your library?
I’ve tried it. but I can’t figure out how to call objective c code
from c code.
Also, I want to keep the compilation easy (I use python distutils to
make the module).
I’ve partially solved calling NSApplicationLoad() before creating the
window.
Now I get some leaks as before but the app works, even if I can’t
receive keyboard events in
windowed mode.
It seems to me that I can’t stick to plain c in the macosx code, like
I did for win and linux version.
Maybe there’s a plain c api to just initializa Cocoa, disable what I
guess is a kind of obj-c garbage
collection, and give focus to the sdl event manager in my window?
Check out pygame CVS and look at the source. It does this all
correctly, from pure Python code no less (via PyObjC), I’m not sure why
you didn’t listen to me the first time. I’m also not sure why you’re
writing another python binding for SDL instead of just extending
pygame. The relevant module is, unsurprisingly, pygame.macosx.
As far as calling Objective-C code from C code, you can’t. You can’t
call C++ code from C code either. The solution to either is similar,
write a C function in the Objective-C module, and link to it.
Distutils understands well enough that .m files should get compiled by
GCC, so linking in SDLmain.m or something like it wouldn’t cause any
problems.
Bob Ippolito wrote:> On Mar 13, 2005, at 8:28, Cesare wrote:
/Recently I’ve converted a SDL/OpenGL app with python embedded to a
/>/python library.
/
/Under MacOS X I get hundreds of NSAutoreleaseNoPool errors when the c
/>/code calls SDL_Init_Video.
/>/
/>/The problem, I believe, is that under MacOS X SDL is implemented
upon
/>/Cocoa. It expects that I run an application with a main(). But in my
/>/case the main loop is in the python script, which call
SDL_Init_Video
/>/and everything else in a function inside the c extension.
/
Can you not call the initialization that is in SDLmain.m normally in
from your library?
I’ve tried it. but I can’t figure out how to call objective c code
from c code.
Also, I want to keep the compilation easy (I use python distutils to
make the module).
I’ve partially solved calling NSApplicationLoad() before creating the
window.
Now I get some leaks as before but the app works, even if I can’t
receive keyboard events in
windowed mode.
It seems to me that I can’t stick to plain c in the macosx code, like
I did for win and linux version.
Maybe there’s a plain c api to just initializa Cocoa, disable what I
guess is a kind of obj-c garbage
collection, and give focus to the sdl event manager in my window?
Check out pygame CVS and look at the source. It does this all
correctly, from pure Python code no less (via PyObjC), I’m not sure
why you didn’t listen to me the first time. I’m also not sure why
you’re writing another python binding for SDL instead of just
extending pygame. The relevant module is, unsurprisingly, pygame.macosx.
As far as calling Objective-C code from C code, you can’t. You can’t
call C++ code from C code either. The solution to either is similar,
write a C function in the Objective-C module, and link to it.
Distutils understands well enough that .m files should get compiled by
GCC, so linking in SDLmain.m or something like it wouldn’t cause any
problems.
I did listen to you.
I didn’t want to add another library dependence (PyObjC). I want my
module to be easy to complile and use.
I know that there’s already PyOpenGL, and that it can work upon PyGame.
But I need something different for my purpose.
I’m trying to do for python what proce55ing (www.processing.org) is for
java. A simplified environment for teching and playing with graphic
programming.
I also want the source code to be as clear and tweakable as possible.
Current version (www.cesaremarilungo.com/blog/devachan.htm) works
flawlessly on Windows and Linux. It used to work flawlessly on MacOS X
when wrapped with SDLmain.m as an app.
/Recently I’ve converted a SDL/OpenGL app with python embedded to a
/>/python library.
/
/Under MacOS X I get hundreds of NSAutoreleaseNoPool errors when
the c
/>/code calls SDL_Init_Video.
/>/
/>/The problem, I believe, is that under MacOS X SDL is implemented
upon
/>/Cocoa. It expects that I run an application with a main(). But
in my
/>/case the main loop is in the python script, which call
SDL_Init_Video
/>/and everything else in a function inside the c extension.
/
Can you not call the initialization that is in SDLmain.m normally
in from your library?
I’ve tried it. but I can’t figure out how to call objective c code
from c code.
Also, I want to keep the compilation easy (I use python distutils to
make the module).
I’ve partially solved calling NSApplicationLoad() before creating
the window.
Now I get some leaks as before but the app works, even if I can’t
receive keyboard events in
windowed mode.
It seems to me that I can’t stick to plain c in the macosx code,
like I did for win and linux version.
Maybe there’s a plain c api to just initializa Cocoa, disable what I
guess is a kind of obj-c garbage
collection, and give focus to the sdl event manager in my window?
Check out pygame CVS and look at the source. It does this all
correctly, from pure Python code no less (via PyObjC), I’m not sure
why you didn’t listen to me the first time. I’m also not sure why
you’re writing another python binding for SDL instead of just
extending pygame. The relevant module is, unsurprisingly,
pygame.macosx.
As far as calling Objective-C code from C code, you can’t. You can’t
call C++ code from C code either. The solution to either is similar,
write a C function in the Objective-C module, and link to it.
Distutils understands well enough that .m files should get compiled
by GCC, so linking in SDLmain.m or something like it wouldn’t cause
any problems.
I did listen to you.
I didn’t want to add another library dependence (PyObjC). I want my
module to be easy to complile and use.
I know that there’s already PyOpenGL, and that it can work upon PyGame.
But I need something different for my purpose.
I’m trying to do for python what proce55ing (www.processing.org) is
for java. A simplified environment for teching and playing with
graphic programming.
I also want the source code to be as clear and tweakable as possible.
Current version (www.cesaremarilungo.com/blog/devachan.htm) works
flawlessly on Windows and Linux. It used to work flawlessly on MacOS X
when wrapped with SDLmain.m as an app.
OK. I’ll try to investingate in this direction.
It’s a reasonable expectation that a Mac OS X user of Python should
have PyObjC. They’re going to need py2app anyway, if they want to
build standalone applications. The PyObjC installer is intentionally
the easiest way to get py2app.
Leaving the Cocoa bootstrap code in Python is the most clear and
tweakable. The code I referred you to doesn’t even execute if the user
sets up their own NSApplication, so it gives them all the flexibility
they need.
-bobOn Mar 14, 2005, at 4:13, Cesare @ Poetic Studios wrote:
Question:
When does the program set event.type to SDL_QUIT, if
there are no mouse or keyboard actions and there are
no SDL_Quit() calls in the code?
Some background information:
OS: Windows 2000
Compiler environment: Visual C++ 6.0
I have a medium sized program, which seems to behave
strangely. The debug version of the program works
normally, but release version closes the program by
itself, but only if I add this line inside the loop:
unsigned int a = SDL_GetTicks();
Another weird thing is, that if I add it inside the
update() function, which is called from the loop,
program doesn’t terminate.
The loop itself calls several different classes and
functions in them, but to simplify, it looks like
this:
----- file main.cpp ---------
while( 1 )
{
// If SDL_GetTicks() call is added here,
// program will terminate
a.update();
}
---- file a.cpp --------
SDL_Init() is called in this class, but before the
while-loop in main.cpp.
a::update()
{
// If SDL_GetTicks() call is added here, program
// WONT terminate.
SDL_Event event;
SDL_PollEvent(&event);
switch (event.type)
{
case SDL_QUIT:
// This is called
return 0;
break;
default:
break;
}
}
I commented out every single SDL_Quit(); call from my
code. And I know I’m not closing the window with
keyboard or mouse. Yet, the event.type seems to get
value SDL_QUIT and the program closes nicely, but
unwantedly. The program can actually stay on for
several seconds before closing, but sometimes it
happenes almost instantly.__________________________________
Do you Yahoo!?
Yahoo! Sports - Sign up for Fantasy Baseball. http://baseball.fantasysports.yahoo.com/
/Recently I’ve converted a SDL/OpenGL app with python embedded to a
/>/python library.
/
/Under MacOS X I get hundreds of NSAutoreleaseNoPool errors when
the c
/>/code calls SDL_Init_Video.
/>/
/>/The problem, I believe, is that under MacOS X SDL is
implemented upon
/>/Cocoa. It expects that I run an application with a main(). But
in my
/>/case the main loop is in the python script, which call
SDL_Init_Video
/>/and everything else in a function inside the c extension.
/
Can you not call the initialization that is in SDLmain.m normally
in from your library?
I’ve tried it. but I can’t figure out how to call objective c code
from c code.
Also, I want to keep the compilation easy (I use python distutils
to make the module).
I’ve partially solved calling NSApplicationLoad() before creating
the window.
Now I get some leaks as before but the app works, even if I can’t
receive keyboard events in
windowed mode.
It seems to me that I can’t stick to plain c in the macosx code,
like I did for win and linux version.
Maybe there’s a plain c api to just initializa Cocoa, disable what
I guess is a kind of obj-c garbage
collection, and give focus to the sdl event manager in my window?
Check out pygame CVS and look at the source. It does this all
correctly, from pure Python code no less (via PyObjC), I’m not sure
why you didn’t listen to me the first time. I’m also not sure why
you’re writing another python binding for SDL instead of just
extending pygame. The relevant module is, unsurprisingly,
pygame.macosx.
As far as calling Objective-C code from C code, you can’t. You
can’t call C++ code from C code either. The solution to either is
similar, write a C function in the Objective-C module, and link to
it. Distutils understands well enough that .m files should get
compiled by GCC, so linking in SDLmain.m or something like it
wouldn’t cause any problems.
I did listen to you.
I didn’t want to add another library dependence (PyObjC). I want my
module to be easy to complile and use.
I know that there’s already PyOpenGL, and that it can work upon PyGame.
But I need something different for my purpose.
I’m trying to do for python what proce55ing (www.processing.org) is
for java. A simplified environment for teching and playing with
graphic programming.
I also want the source code to be as clear and tweakable as
possible. Current version
(www.cesaremarilungo.com/blog/devachan.htm) works flawlessly on
Windows and Linux. It used to work flawlessly on MacOS X when wrapped
with SDLmain.m as an app.
OK. I’ll try to investingate in this direction.
It’s a reasonable expectation that a Mac OS X user of Python should
have PyObjC. They’re going to need py2app anyway, if they want to
build standalone applications. The PyObjC installer is intentionally
the easiest way to get py2app.
Leaving the Cocoa bootstrap code in Python is the most clear and
tweakable. The code I referred you to doesn’t even execute if the
user sets up their own NSApplication, so it gives them all the
flexibility they need.
Think I’ll go that way. At least the additional dependency will only
affect MacOS X users.
I also noticed that wxWindows, which I wanted to use to use to create a
GUI for my project, still doesn’t support OpenGL on Mac. Apple should
have included a X11 implementation in his OS.
Thanks, btw.
c.> On Mar 14, 2005, at 4:13, Cesare @ Poetic Studios wrote:
/Recently I’ve converted a SDL/OpenGL app with python embedded
to a
/>/python library.
/
/Under MacOS X I get hundreds of NSAutoreleaseNoPool errors
when the c
/>/code calls SDL_Init_Video.
/>/
/>/The problem, I believe, is that under MacOS X SDL is
implemented upon
/>/Cocoa. It expects that I run an application with a main().
But in my
/>/case the main loop is in the python script, which call
SDL_Init_Video
/>/and everything else in a function inside the c extension.
/
Can you not call the initialization that is in SDLmain.m
normally in from your library?
I’ve tried it. but I can’t figure out how to call objective c
code from c code.
Also, I want to keep the compilation easy (I use python distutils
to make the module).
I’ve partially solved calling NSApplicationLoad() before creating
the window.
Now I get some leaks as before but the app works, even if I can’t
receive keyboard events in
windowed mode.
It seems to me that I can’t stick to plain c in the macosx code,
like I did for win and linux version.
Maybe there’s a plain c api to just initializa Cocoa, disable
what I guess is a kind of obj-c garbage
collection, and give focus to the sdl event manager in my window?
Check out pygame CVS and look at the source. It does this all
correctly, from pure Python code no less (via PyObjC), I’m not
sure why you didn’t listen to me the first time. I’m also not
sure why you’re writing another python binding for SDL instead of
just extending pygame. The relevant module is, unsurprisingly,
pygame.macosx.
As far as calling Objective-C code from C code, you can’t. You
can’t call C++ code from C code either. The solution to either is
similar, write a C function in the Objective-C module, and link to
it. Distutils understands well enough that .m files should get
compiled by GCC, so linking in SDLmain.m or something like it
wouldn’t cause any problems.
I did listen to you.
I didn’t want to add another library dependence (PyObjC). I want my
module to be easy to complile and use.
I know that there’s already PyOpenGL, and that it can work upon
PyGame.
But I need something different for my purpose.
I’m trying to do for python what proce55ing (www.processing.org) is
for java. A simplified environment for teching and playing with
graphic programming.
I also want the source code to be as clear and tweakable as
possible. Current version
(www.cesaremarilungo.com/blog/devachan.htm) works flawlessly on
Windows and Linux. It used to work flawlessly on MacOS X when
wrapped with SDLmain.m as an app.
OK. I’ll try to investingate in this direction.
It’s a reasonable expectation that a Mac OS X user of Python should
have PyObjC. They’re going to need py2app anyway, if they want to
build standalone applications. The PyObjC installer is
intentionally the easiest way to get py2app.
Leaving the Cocoa bootstrap code in Python is the most clear and
tweakable. The code I referred you to doesn’t even execute if the
user sets up their own NSApplication, so it gives them all the
flexibility they need.
Think I’ll go that way. At least the additional dependency will only
affect MacOS X users.
I also noticed that wxWindows, which I wanted to use to use to create
a GUI for my project, still doesn’t support OpenGL on Mac. Apple
should have included a X11 implementation in his OS.
Apple does include an X11 implementation with Mac OS X 10.3 and later,
and they offered one for download for Mac OS X 10.2. However, in both
cases it’s optional and not installed by default. Most users wouldn’t
tolerate X11, as it doesn’t integrate well with the rest of the OS, so
it’s not such a bad thing that developers are encouraged not to use it.
-bobOn Mar 14, 2005, at 1:31 PM, Cesare @ Poetic Studios wrote:
On Mar 14, 2005, at 4:13, Cesare @ Poetic Studios wrote:
I also noticed that wxWindows, which I wanted to use to use to create
a GUI for my project, still doesn’t support OpenGL on Mac.
Actually, as far as I know, wxWindows (aka wxWidgets) does support
OpenGL on the Mac. I had successfully used it as of version 2.4.2.
Apple
should have included a X11 implementation in his OS.
Apple does include an X11 implementation with Mac OS X 10.3 and later,
and they offered one for download for Mac OS X 10.2. However, in both
cases it’s optional and not installed by default. Most users wouldn’t
tolerate X11, as it doesn’t integrate well with the rest of the OS, so
it’s not such a bad thing that developers are encouraged not to use it.
I agree with Bob. Mac users would probably curse you for forcing them
to run through X11. Apple provides X11 as a convenience tool to help
you transition or port applications from X11. But it is not encouraged
to be used as a foundation for a new application.
Please read SDL_PollEvent() documentation
(http://sdldoc.csn.ul.ie/sdlpollevent.php). When SDL_PollEvent() returns 0,
there are no event available. This means you test a memory area that has not
been initialized.
I also noticed that wxWindows, which I wanted to use to use to create
a GUI for my project, still doesn’t support OpenGL on Mac.
Actually, as far as I know, wxWindows (aka wxWidgets) does support
OpenGL on the Mac. I had successfully used it as of version 2.4.2.
I do believe you. The info page on their site says that OpenGL is
supported only on GTK and Windows.
But I’ve already found resources about people actually using it.
Apple
should have included a X11 implementation in his OS.
Apple does include an X11 implementation with Mac OS X 10.3 and later,
and they offered one for download for Mac OS X 10.2. However, in both
cases it’s optional and not installed by default. Most users wouldn’t
tolerate X11, as it doesn’t integrate well with the rest of the OS, so
it’s not such a bad thing that developers are encouraged not to use it.
I agree with Bob. Mac users would probably curse you for forcing them
to run through X11. Apple provides X11 as a convenience tool to help
you transition or port applications from X11. But it is not encouraged
to be used as a foundation for a new application.
-Eric
I disagree with you and with Bob.
I just need to draw into a f***ing window. Don’t need any other MacOS
specific technology.
I guess you agree that MacOS X is more similar to Linux than Windows.
But I can compile my code on
the last two platform with no runtime errors. The same code doesn’t work
on OS X.
Also, I think that this solution is technically more a workaround than a
clean solution.
I want my python code to be able to open a window. I’m not launching an
application - with a main loop.
Here the main loop is inside the python code.
Maybe I’m just nostalgic for those early years when opening a window in
MacOS was actually a system call in ROM. :-)>_______________________________________________
