[sac-user] SDL running on Mac OS X

Wed Apr 14 09:10:59 BST 2010

Hi Robert,

I wonder a bit whether SDL on MAC OS X is completely different in its requirements
from Linux or if the Linux SDL implementation is just a bit sloppy and accepts
program code that strictly speaking is wrong. Do you have an idea?

I do not think that sac4c is the silver bullet. Giving the control over your
application to a C environment has a number of implications that are similarly
undesirable. You alread identified the object problem. It is also not a very
convenient solution for the programmer to take care of all that rather than
just using some nice SAC wrappers.

  Clemens

Robert de Groote wrote:
> Hi Clemens,
> 
> I thought it would be not too difficult to get SDL working with SaC, but it turned out to be quite hard, it's as if SaC & SDL were designed not to interoperate, at least not on the Mac.
> 
>> Hi Robert,
>>
>> Many thanks for sharing your SAC+SDL experience with us. As Carl already pointed out,
>> our main SDL expert Stephan is currently on a well-deserved holiday.
>>
>> Robert de Groote wrote:
>>> Hi list,
>>> During the S-Hack 2010 tutorial in Hatfield, I've been trying to get a simple SaC-mandelbrot app running with SDL on my Mac. Initially I got it working but the window was unresponsive and my console was listing loads and loads of memory leak warnings. I've advanced a bit further now, and have a responsive mandelbrot application without memory leak warnings running with SDL on my Mac. I'd like to start a discussion on the steps that are involved to get all of this working, as there are quite a few things I had to change in SaC's standard library code:
>>> First of all, the steps listed below apply to my Mac, I don't know whether they would break code that currently works fine on other platforms.
>>> The mandelbrot app can be found in $SACBASE/sac/tutorials/L8_case_study_mandelbrot.
>>> The first thing to to in order to get a program running with SDL is to include SDL.h in the c file generated by sac2c. This enables SDL to replace your main function with the SDLmain function, which is the entry-point for SDL apps.
>>> For more details, check out http://www.libsdl.org/faq.php?action=listentries&category=7#55
>> Reading the documentation I wonder why this has not been the case already (and something
>> worked on other systems). However, bear in mind that not every SAC program is an SDL
>> program. Actually, very few are. So, this is not as simple as in a specific program.
>> The compiler would need to identify an SDL application, e.g. through the presence of
>> certain symbols, and place the include only on demand.
> 
> Well, SDL.h is included by SDLsac.h, which is in the stdlib/world/stdio module. However, it is not explicitly included by the c-file generated by sac2c. On other systems, there probably is no need for including that header file. On Mac OS X, the way an SDL app is run differs - SDL needs to run your application. I think I've come across a few posts in different forums saying that this mechanism on Mac OS X is a bit weird, and I also don't quite know why it is set up the way it is. So I guess the compiler would need to check whether it's MacOS && SDL, which I would not know how to do automatically. 
> 
>>> Using the stdlib of SaC, after including SDL.h in the file produced by sac2c the mandelbrot app runs, but does not respond to any events (spinning beachball) and the terminal is busy spitting out memory leak warnings (NSAutoreleasePool ....). The reason for this is that SDL on the Mac is implemented in objective C, and objective C requires you to either set up a so-called "Auto release pool" for garbage collection (or explicitly free objects after you're done with them). SDL seems to assume that such a pool is in place. Now, the SDLmain entry-point for the mandelbrot app sets up such a pool, so the main thread has such a pool in place. However, SaC's standard library creates a few threads (event handler, timer and possibly screen-updater) which invoke SDL functions, which allocate objective C objects. Because each thread is responsible for setting up its own memory management, no auto-release-pools are created for these threads, causing all the memory leak warnings.
>>> There are two ways of solving this. First, a thread that is created could set up its own auto-release-pool before starting work. Another option is to simply keep all calls to SDL in the main thread.
>>> I started by implementing the first solution: I've implemented a very simple thread-wrapping library in objective C that basically wraps SDL_CreateThread - it first creates an auto-release pool before handing control over to the worker function. However, this solves the memory-leak warnings but does not make the window responsive.
>> That should be doable in the stdlib as well.
> 
> I've sent my code for wrapping these threads to Carl.
> 
> One thing that I found weird here is that the SDL documentation mentions that events can only be handled in the thread that set up the video (by calling SDL_Init), which is not the way initDisplay.c in the stdlib works. It still works though (but not on Mac OS X). The SDL documentation also mentions that in threads created with SDL_CreateThread *no* SDL library functions should be called, which seems to be somewhat strict.
> 
>>> Supposedly on Mac OS X, events that are sent to the app (main thread) are not dispatched to the threads created by the main thread. SaC's standard library creates a separate (SDL) thread to handle events, but this thread never receives any events, rendering the window unresponsive.
>>> To solve this problem, I had to make a lot of changes to the event handling of SaC's standard library. I created a simple SDL event loop that is supposed to be run in the main thread. A simple library allows the user to register callback functions for incoming events, and to call SDL functions asynchronously. This way, I am able to run the application code in a separate thread, while keeping the main SDL event loop in the main thread. The application thread can still interact with SDL, but asynchronously.
>> That sounds like quite some work to get it going, in particular we cannot have SDL support
>> as a stdlib solution, at least not a pure one. We would instead need to identify the need
>> for SDL support (again) and then generate completely different code around main().
> 
> Carl mentioned that this might be something for sac4c - if you want to use SDL, write your code as a module that is initialized by a C program that sets up SDL and calls your SaC "module main". However, I tried using sac4c but got into trouble because of globals "theWorld" and "theTerminal".
> 
>>> What I would like to achieve with this e-mail, is that most of the steps that need to be taken in order to get SDL working with SaC on the Mac are performed by sac2c. The easiest step is adding "#include "SDL.h" to the c output. The other, more difficult step is to generate a main function that spawns a separate thread for the application code, and after doing so enters the main SDL event loop. I do realise that the way I've described the steps I've taken could be structured a bit better, so forgive me for this chronological dump of events :-).
>> You're right. All this should be done automatically by sac2c either by identifying
>> a dependency to SDL or simply triggered by a command line flag. We shall discuss this
>> issue on the next SAC developer meeting. It would be very nice to incorporate your
>> findings into sac2c to have (more) proper SDL support in the future.
>>
> 
> I'll be happy to help :-)
> 
> Regards,
> Robert
> 
> 

-- 
Dr Clemens Grelck
Assistant Professor in Compiler Design
University of Amsterdam
Informatics Institute
Computer Systems Architecture
http://www.science.uva.nl/~grelck